[Bug c/40536] New: comma at end of enumerator list in bits/resource.h in pedantic mode
Dear all,
When I try to compile the sample code at the end of this report with
gcc -ansi -pedantic-errors -Wall essai.c -o essai, I get the error :
/usr/include/bits/resource.h:161: erreur: comma at end of enumerator list
If I remove the -pedantic-errors, the compilation goes fine.
Here is the sample code :
#include stdio.h
#include sys/time.h
#include sys/resource.h
int
main ()
{
struct rlimit rlp;
int CR;
CR = getrlimit (RLIMIT_DATA, rlp);
if (CR == 0)
{
if (rlp.rlim_cur == RLIM_INFINITY)
{
fputs (infinity\n, stdout);
}
else
{
fprintf (stdout, %ld\n, rlp.rlim_cur);
}
}
else
{
fputs (unknown\n, stdout);
fprintf (stderr, getrlimit error, code=%d\n, CR);
return 1;
}
return 0;
}
--
Summary: comma at end of enumerator list in bits/resource.h in
pedantic mode
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bpiguet at teaser dot fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40536
[Bug c/40536] comma at end of enumerator list in bits/resource.h in pedantic mode
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-06-24 06:16 --- /usr/include/bits/resource.h is not controlled by GCC. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40536
[Bug c/40536] comma at end of enumerator list in bits/resource.h in pedantic mode
--- Comment #2 from bpiguet at teaser dot fr 2009-06-24 06:28 --- (In reply to comment #1) /usr/include/bits/resource.h is not controlled by GCC. OK. Before I make the same error again, any hints on the project which controls /usr/include/bits/resource.h ? I guess it might be libc, am I wrong ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40536
[Bug testsuite/40532] FAIL: gcc.dg/builtins-65.c (test for excess errors)
--- Comment #1 from ubizjak at gmail dot com 2009-06-24 06:35 --- Can you put HAVE_C99_RUNTIME around problematic conversions (just copy the approach from builtins-18.c) ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40532
[Bug middle-end/40501] [4.5 Regression] error: invalid conversion in gimple call
--- Comment #6 from krebbel at gcc dot gnu dot org 2009-06-24 07:01 --- Subject: Bug 40501 Author: krebbel Date: Wed Jun 24 07:01:24 2009 New Revision: 148892 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=148892 Log: 2009-06-24 Andreas Krebbel krebb...@de.ibm.com PR middle-end/40501 * tree-ssa-math-opts.c (execute_optimize_bswap): Convert the bswap src and dst operands if necessary. 2009-06-24 Andreas Krebbel krebb...@de.ibm.com * gcc.dg/pr40501.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/pr40501.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-math-opts.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40501
[Bug libstdc++/40297] [C++0x] debug mode vs atomics
--- Comment #5 from redi at gcc dot gnu dot org 2009-06-24 07:06 --- Subject: Bug 40297 Author: redi Date: Wed Jun 24 07:06:17 2009 New Revision: 148893 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=148893 Log: 2009-06-24 Jonathan Wakely jwakely@gmail.com PR libstdc++/40297 * include/bits/atomic_0.h: Reverse debug assertions. * include/bits/atomic_2.h: Likewise. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/atomic_0.h trunk/libstdc++-v3/include/bits/atomic_2.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40297
[Bug libstdc++/40297] [C++0x] debug mode vs atomics
--- Comment #6 from redi at gcc dot gnu dot org 2009-06-24 07:08 --- Subject: Bug 40297 Author: redi Date: Wed Jun 24 07:07:49 2009 New Revision: 148894 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=148894 Log: 2009-06-24 Jonathan Wakely jwakely@gmail.com PR libstdc++/40297 * include/bits/atomic_0.h: Reverse debug assertions. * include/bits/atomic_2.h: Likewise. Modified: branches/gcc-4_4-branch/libstdc++-v3/ChangeLog branches/gcc-4_4-branch/libstdc++-v3/include/bits/atomic_0.h branches/gcc-4_4-branch/libstdc++-v3/include/bits/atomic_2.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40297
[Bug libstdc++/40297] [C++0x] debug mode vs atomics
--- Comment #7 from jwakely dot gcc at gmail dot com 2009-06-24 07:09 --- Fixed for 4.4.1 and 4.5.0 -- jwakely dot gcc at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40297
[Bug tree-optimization/34737] Scheduling of post-modified function arguments is not good
--- Comment #4 from steven at gcc dot gnu dot org 2009-06-24 07:42 --- Couldn't this be fixed also by changing the initial gimplification from: p.0 = p; p = p + 1; foo (p.0); to: p.0 = p; foo (p.0); p = p + 1; ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34737
[Bug middle-end/35141] ARM: Constant generation inside a loop: Missed optimization opportunity
--- Comment #9 from steven at gcc dot gnu dot org 2009-06-24 07:45 --- I agree with Comment #8 -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35141
[Bug middle-end/28685] Multiple comparisons are not simplified
--- Comment #7 from steven at gcc dot gnu dot org 2009-06-24 07:49 --- How are things progressing with a fix for this, Richi? :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28685
[Bug target/40537] wrong instr. dependency with some SSE intrinsics
--- Comment #1 from gael dot guennebaud at gmail dot com 2009-06-24 08:07 --- Created an attachment (id=18055) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18055action=view) a complete example showing the problem usage: Works: g++ -O3 instr_dependency.cpp -o instr_dependency ./instr_dependency Fails: g++ -O3 instr_dependency.cpp -o instr_dependency -DFAST ./instr_dependency -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40537
[Bug tree-optimization/34737] Scheduling of post-modified function arguments is not good
--- Comment #5 from rguenther at suse dot de 2009-06-24 09:07 --- Subject: Re: Scheduling of post-modified function arguments is not good On Wed, 24 Jun 2009, steven at gcc dot gnu dot org wrote: --- Comment #4 from steven at gcc dot gnu dot org 2009-06-24 07:42 --- Couldn't this be fixed also by changing the initial gimplification from: p.0 = p; p = p + 1; foo (p.0); to: p.0 = p; foo (p.0); p = p + 1; Probably yes. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34737
[Bug middle-end/28685] Multiple comparisons are not simplified
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-06-24 09:15 --- :P I am currently not working on a fix for this (heh, people may have noticed that ...). My idea was to build an on-the-side CFG for this and use that in tree-ssa-ifcombine.c - I just never came around implementing that. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org AssignedTo|rguenth at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28685
[Bug tree-optimization/40529] ICE with -floop-block, verify_ssa failed
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-06-24 09:42 --- ICEs with -O -ffast-math -floop-block: source/blender/radiosity/intern/source/radfactors.c: In function 'calcSidefactors': source/blender/radiosity/intern/source/radfactors.c:192: error: definition in block 4 does not dominate use in block 30 for SSA_NAME: ysq_19 in statement: D.7069_152 = ysq_19 + 1.0e+0; source/blender/radiosity/intern/source/radfactors.c:192: internal compiler error: verify_ssa failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. also ICEs the same way on the trunk. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||spop at gcc dot gnu dot org Component|middle-end |tree-optimization Keywords||ice-on-valid-code Known to fail||4.4.0 4.5.0 Summary|Build fails with an internal|ICE with -floop-block, |compiler error. |verify_ssa failed http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40529
[Bug c/40517] strict-aliasing warning contains internal variable name
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-06-24 09:43 --- It's not available. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40517
[Bug c/40536] comma at end of enumerator list in bits/resource.h in pedantic mode
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-06-24 09:45 --- Yes, it's from libc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40536
[Bug target/40537] wrong instr. dependency with some SSE intrinsics
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-06-24 09:48 --- I can't verify it (you do not provide complete source that can be compiled), but I think this is a duplicate of PR40141 which is fixed in GCC 4.4. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40537
[Bug target/37629] auto-import of constant data results in a crash at runtime
--- Comment #5 from ktietz at gcc dot gnu dot org 2009-06-24 10:11 --- This bug is fixed within ld (by using pseudo-relocation) and within startup code. For new runtimes this bug is fixed also for 32-bit mingw. There is no limit about const variables exported without dllimport anymore present for mingw targets -- ktietz at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37629
[Bug target/37750] a lot of crashes with tree optimizations on mingw
--- Comment #10 from ktietz at gcc dot gnu dot org 2009-06-24 10:17 --- Does this issue appears also, when using builtin alloca version? As I noticed does the switch -fno-builtin shows explict broken _alloca for x64. The call-save area isn't adjusted and compiler seems not to take care here -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37750
[Bug c++/35159] g++ and gfortran inoperable with no error message
--- Comment #25 from ktietz at gcc dot gnu dot org 2009-06-24 10:28 --- This bug was fixed for 4.4 version. The real issue here was the changes happend to ira and specifying one register via the constrains =a or +a. Both variant don't work anymore. By expanding the stack_allocator methods (for 32-bit and 64-bit) by one input and one output contrain, it solves the issue. -- ktietz at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35159
[Bug target/40537] wrong instr. dependency with some SSE intrinsics
--- Comment #3 from gael dot guennebaud at gmail dot com 2009-06-24 10:53
---
There is a compilable example attached to comment #1.
Furthermore, I can reproduce the problem with gcc 4.1.3, 4.2.4, 4.3.2, and
4.4.0, so I don't think it is a duplicate of PR40141.
FYI, in the meantime I workaround the issue using inline assembly:
inline __m128 ploadu(const float* from)
{
__m128 res;
asm(movsd %[from0], %[r]
: [r] =x (res) : [from0] m (*from), [dummy] m (*(from+1)) );
asm(movhps %[from2], %[r]
: [r] +x (res) : [from2] m (*(from+2)), [dummy] m (*(from+3)) );
return res;
}
but that's not as portable as intrinsics.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40537
[Bug fortran/40427] [F03] Procedure Pointer Components with OPTIONAL arguments
--- Comment #2 from janus at gcc dot gnu dot org 2009-06-24 11:00 --- Subject: Bug 40427 Author: janus Date: Wed Jun 24 10:59:56 2009 New Revision: 148906 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=148906 Log: 2009-06-24 Janus Weil ja...@gcc.gnu.org PR fortran/40427 * gfortran.h (gfc_component): New member 'formal_ns'. (gfc_copy_formal_args_ppc,void gfc_ppc_use): New. * interface.c (gfc_ppc_use): New function, analogous to gfc_procedure_use, but for procedure pointer components. * module.c (MOD_VERSION): Bump module version. (mio_component): Treat formal arguments. (mio_formal_arglist): Changed argument from gfc_symbol to gfc_formal_arglist. (mio_symbol): Changed argument of mio_formal_arglist. * resolve.c (resolve_ppc_call,resolve_expr_ppc): Call gfc_ppc_use, to check actual arguments and treat formal args correctly. (resolve_fl_derived): Copy formal args of procedure pointer components from their interface. * symbol.c (gfc_copy_formal_args_ppc): New function, analogous to gfc_copy_formal_args, but for procedure pointer components. 2009-06-24 Janus Weil ja...@gcc.gnu.org PR fortran/40427 * gfortran.dg/proc_ptr_comp_11.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/proc_ptr_comp_11.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/interface.c trunk/gcc/fortran/module.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/symbol.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40427
[Bug fortran/40427] [F03] Procedure Pointer Components with OPTIONAL arguments
--- Comment #3 from janus at gcc dot gnu dot org 2009-06-24 11:02 --- Fixed with r148906. 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=40427
[Bug target/40537] wrong instr. dependency with some SSE intrinsics
--- Comment #4 from gael dot guennebaud at gmail dot com 2009-06-24 11:12
---
some additional info:
- compiling with -fno-strict-aliasing fix the issue, so perhaps this is not a
real bug but a feature ?
- on the other hand using the may_alias type attribute for casting does not
help:
inline __m128 ploadu(const float* from) {
typedef double __attribute__((may_alias)) doubleA;
typedef __m128 __attribute__((may_alias)) __m128A;
__m128 r;
r = (__m128A)(_mm_load_sd( (const doubleA*)(from) ));
r = _mm_loadh_pi(r, (const __m64*)(from+2));
return r;
}
I guess this is because the const doubleA* is then casted to a const
double* when calling the _mm_load_sd() function.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40537
[Bug target/40537] wrong instr. dependency with some SSE intrinsics
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-06-24 11:23 ---
There are aliasing issues with your code / the intrinsics implementation:
float data[4] = {1, 2, 3, 4};
...
r = _mm_castpd_ps(_mm_load_sd((double*)(from)));
ends up loading from float data via a pointer to double. That is invalid
unless the intrinsic specifies it should work ok in which case it better
had implemented counter-measures here:
data[0] ={v} 1.0e+0;
data[1] ={v} 2.0e+0;
data[2] ={v} 3.0e+0;
data[3] ={v} 4.0e+0;
from.92_14 = (const double *) data[0];
D.25303_15 = *from.92_14;
D.25304_16 = {D.25303_15, 0.0};
r_17 = VIEW_CONVERT_EXPR__m128(D.25304_16);
I would suggest using
typedef double __attribute__((may_alias)) aliased_double;
r = _mm_castpd_ps(_mm_set_sd (*(aliased_double *)from));
instead.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40537
[Bug target/37750] a lot of crashes with tree optimizations on mingw
--- Comment #11 from sherpya at netfarm dot it 2009-06-24 11:42 --- I'm using 4.5 from svn, with -O2 and looks like not affected 4.3 and 4.4 are almost unusable on mingw (at least my builds) something changed in 4.5 branch, I've not tested further 4.3 or .4.4 since I was using 4.2 then switched to 4.5 when it started to work on mingw -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37750
[Bug target/40537] wrong instr. dependency with some SSE intrinsics
--- Comment #7 from ubizjak at gmail dot com 2009-06-24 11:57 --- Adding x86 intrinsic expert... -- ubizjak at gmail dot com changed: What|Removed |Added CC||hjl dot tools at gmail dot ||com Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-06-24 11:57:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40537
[Bug target/37120] g++ failed to compile code dVolume *= 1 + pow(10.0, -5.0);
--- Comment #6 from ktietz at gcc dot gnu dot org 2009-06-24 11:57 --- I tried to reproduce this with 4.4 and 4.5 and it seems to work for me. Do you still have this issue? Kai -- ktietz at gcc dot gnu dot org changed: What|Removed |Added CC||ktietz at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37120
[Bug fortran/40539] New: Inversion of logical function compiled with ifort not correct.
I'm attaching a very simple reproducer which, if compiled like following way:
ifort -c lsame.f
gfortran repr.f lsame.o
produces a wrong negation of a logical value returned by function LSAME(a
simpified analogue for LAPACK one available in attach). The value for
.NOT.LSAME('D','D') and LSAME('D','D') are both true. So it looks like
something wrong on GFORTRAN side.
If I use gfortran 4.2.0 or compile lsame with any gfortran, the logical results
are correct.
Change of Intel compiler version ( 9.1, 10.1 were tested ) doesn't affect
result.
This reproducable for ia32 and Intel64 architectures.
--
Summary: Inversion of logical function compiled with ifort not
correct.
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: alexander dot v dot kobotov at intel dot com
GCC host triplet: Linux 2.6.16.46-0.12-smp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40539
[Bug target/36834] structure return ABI for windows targets differs from native MSVC
--- Comment #12 from ktietz at gcc dot gnu dot org 2009-06-24 12:05 --- As I read this. Would it make sense to use for x86-mingw the callabi feature (as we do for the x64 variant)? This would be useful for 32-bit based multilib version, too (but this is more a side-note for this). Kai -- ktietz at gcc dot gnu dot org changed: What|Removed |Added CC||ktietz at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36834
[Bug fortran/40539] Inversion of logical function compiled with ifort not correct.
--- Comment #1 from alexander dot v dot kobotov at intel dot com 2009-06-24 12:12 --- Created an attachment (id=18056) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18056action=view) The reproducer sources zipped -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40539
[Bug fortran/40539] Inversion of logical function compiled with ifort not correct.
--- Comment #2 from steven at gcc dot gnu dot org 2009-06-24 12:37 --- Not a self-contained bug report: Impossible to reproduce unless you have the intel compiler. Maybe you can attach the assembler output of ifort? -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40539
[Bug c/40540] New: Error compiling with march=atom and GCC 4.5
Since my update to version 4.5 06-18-2009 i have some errors on compiling. Here are my logs for ppp-2.4.4 and xorg-server-1.6.1.901 These are my first packages after compiler update and i think many of the other packages will post the same errors. -- Summary: Error compiling with march=atom and GCC 4.5 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: wuddja at yahoo dot de GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: -march=atom -O2 -pipe -fomit-frame-pointer http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40540
[Bug c/40540] Error compiling with march=atom and GCC 4.5
--- Comment #1 from wuddja at yahoo dot de 2009-06-24 12:46 --- Created an attachment (id=18057) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18057action=view) build log for ppp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40540
[Bug c/40540] Error compiling with march=atom and GCC 4.5
--- Comment #2 from wuddja at yahoo dot de 2009-06-24 12:47 --- Created an attachment (id=18058) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18058action=view) build log for xorg-server -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40540
[Bug fortran/40541] New: Assignment checking for proc-pointer = proc-ptr-returning-function()
Found while looking at PR 39997. The following is not checked. The reason is
that the check contains:
if (rvalue-expr_type == EXPR_VARIABLE
while the example has EXPR_FUNCTION
program test
procedure(real), pointer :: p
p = f() ! Invalid f() returns a LOGICAL(1) function, but p is a REAL one
contains
function f()
pointer :: f
interface
logical(1) function f()
end function
end interface
f = .true._1
end function f
end program test
* * *
Maybe PR 39997 (comment 3) item 3 can be fixed at the same time. One needs just
to add:
If( RHS is a function LHS is untyped) {
implicitly type proc pointer on the LHS
}
before the subroutine/function check is done.
--
Summary: Assignment checking for proc-pointer = proc-ptr-
returning-function()
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: accepts-invalid
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=40541
[Bug fortran/39997] Procedure(), pointer implicit typing: rejects-valid / accepts-invalid?
--- Comment #4 from burnus at gcc dot gnu dot org 2009-06-24 12:59 --- (In reply to comment #3) Regarding the implicit typing: I think it would be easiest to apply the implicit typing for module m external foo end module m at resolution time, such that foo is marked as ts.type = real, ts.kind = 4, but such that one still knows that foo can still be a subroutine. One probably needs another flag, but maybe the one can re-use a current flag without ambiguity arising. The challenge is to find all places where BT_UNKNOWN is checked to for functions/subroutines/procedure (pointers) - be it in interface/symbol/resolve or in trans*.c. We don't need another flag if (!attr.functions attr.implicit_type) can never occur with the current code. Or when we can use attr.untyped somehow. In any case writing a single flag (per symbol) to the .mod file is easier that dumping the complete implicit typing stuff there and applying the right type to the host-associated variable. Another test case, currently works, but still needs to work after fixing the implicit stuff: module m implicit logical(1)(a-z) external proc end module m use m call proc() end * * * Proc-pointer assignment of ptr = Function w/ ptr with ptr being implicitly typed (including null mapping - SUBROUTINE), where the function-return-type does not match the implicit type for ptr: This still does not produce an error. Maybe it can be fixed as part of PR 40541 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39997
[Bug bootstrap/40455] gcc trunk does not bootstrap as of commit r148408
--- Comment #11 from christian dot joensson at gmail dot com 2009-06-24 13:03 --- I have tried binutils cvs checkouts as of 20090608 12:00 UTC 20090519 12:00 UTC 20090502 12:00 UTC 20090402 12:00 UTC 20090309 12:00 UTC as well as cygwin's provided binutils 2.18.50.20080625, all with the same results; the -g -O2 in there makes the a.exe not being able to execute as of gcc trunk commit r148408. I will stop searching backwards for a working binutils now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40455
[Bug target/40537] wrong instr. dependency with some SSE intrinsics
--- Comment #8 from hjl dot tools at gmail dot com 2009-06-24 13:09 --- (In reply to comment #6) _mm_load_sd( (const doubleA*)(from) ) does not work because the prototype of _mm_load_sd does not have a type with the may-alias attribute, so it gets stripped again. I think movsd/movhpd intrinsics with union of double/float or movlps/movhps intrinsics should be used. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40537
[Bug c/40542] New: gcc-4.3.3 vectorizes access to volatile array
gcc-4.3.3 (4.3.2 probably other versions, too)
seems to produce bad code when
accessing an array of small 'volatile'
objects -- it may try to access multiple
such objects in a 'parallel/vectorized' fashion.
-ftree-vectorize seems to be the option
that triggers this behavior.
E.g., instead of reading four consecutive
'volatile char's sequentially it reads
a single 32-bit longword (on x86_64 it
even uses XMM registers to read 16 volatile
chars at once). This may crash
e.g., when accessing a memory-mapped device
which allows only 8-bit accesses.
The vectorized access is preceded by
a single, redundant access of the correct
width implementing something like
for (i=0; i16/vector_size; i++) {
d[i] = s[i];
((vector char*)d)[i] = ((vector char*)s)[i];
}
Look for the statements after '.L6' which
are executed if source and destination are
4-byte (16-byte in case of XMM) aligned
and if src/dst vectors don't overlap.
Both facts (redundant access + vectorized
access) seem to violate C99 (5.1.2.3.2):
At certain specified points in the execution
sequence called 'sequence points', all side
effects of previous evaluations shall be
complete and no side effects of subsequent
evaluations shall have taken place
This rule seems violated at the ';'
sequence point which terminates the
assignment.
void
volarr_cpy(char *d, volatile char *s)
{
int i;
for ( i=0; i16; i++ )
d[i]=s[i];
}
compiled for i386 with gcc-4.3.3 -m32 -O3 -S -c
.file volcharr_cpy.c
.text
.p2align 4,,15
.globl volarr_cpy
.type volarr_cpy, @function
volarr_cpy:
pushl %ebp
movl%esp, %ebp
pushl %esi
pushl %ebx
movl12(%ebp), %ecx
movl8(%ebp), %edx
movl%ecx, %eax
orl %edx, %eax
testb $3, %al
leal4(%ecx), %ebx
leal4(%edx), %esi
je .L8
.L2:
movzbl (%ecx), %eax
movb%al, (%edx)
movzbl 1(%ecx), %eax
movb%al, 1(%edx)
movzbl 2(%ecx), %eax
movb%al, 2(%edx)
movzbl 3(%ecx), %eax
movb%al, 3(%edx)
movzbl 4(%ecx), %eax
movb%al, 4(%edx)
movzbl 5(%ecx), %eax
movb%al, 5(%edx)
movzbl 6(%ecx), %eax
movb%al, 6(%edx)
movzbl 7(%ecx), %eax
movb%al, 7(%edx)
movzbl 8(%ecx), %eax
movb%al, 8(%edx)
movzbl 9(%ecx), %eax
movb%al, 9(%edx)
movzbl 10(%ecx), %eax
movb%al, 10(%edx)
movzbl 11(%ecx), %eax
movb%al, 11(%edx)
movzbl 12(%ecx), %eax
movb%al, 12(%edx)
movzbl 13(%ecx), %eax
movb%al, 13(%edx)
movzbl 14(%ecx), %eax
movb%al, 14(%edx)
movzbl 15(%ecx), %eax
movb%al, 15(%edx)
popl%ebx
popl%esi
popl%ebp
ret
.p2align 4,,7
.p2align 3
.L8:
cmpl%ebx, %edx
jbe .L9
.L6:
movzbl (%ecx), %eax
movl(%ecx), %eax
movl%eax, (%edx)
movzbl 1(%ecx), %eax
movl4(%ecx), %eax
movl%eax, 4(%edx)
movzbl 2(%ecx), %eax
leal4(%ebx), %edx
movl4(%ebx), %eax
movl%eax, 4(%esi)
movzbl 3(%ecx), %eax
movl4(%edx), %eax
movl%eax, 8(%esi)
popl%ebx
popl%esi
popl%ebp
ret
.p2align 4,,7
.p2align 3
.L9:
cmpl%esi, %ecx
jbe .L2
jmp .L6
.size volarr_cpy, .-volarr_cpy
.ident GCC: (Ubuntu 4.3.3-5ubuntu4) 4.3.3
.section.note.GNU-stack,,@progbits
compiled for x86_64 with gcc -S -c -O3
.file volcharr_cpy.c
.text
.p2align 4,,15
.globl volarr_cpy
.type volarr_cpy, @function
volarr_cpy:
.LFB2:
testb $15, %dil
je .L8
.L2:
movzbl (%rsi), %eax
movb%al, (%rdi)
movzbl 1(%rsi), %eax
movb%al, 1(%rdi)
movzbl 2(%rsi), %eax
movb%al, 2(%rdi)
movzbl 3(%rsi), %eax
movb%al, 3(%rdi)
movzbl 4(%rsi), %eax
movb%al, 4(%rdi)
movzbl 5(%rsi), %eax
movb%al, 5(%rdi)
movzbl 6(%rsi), %eax
movb%al, 6(%rdi)
movzbl 7(%rsi), %eax
movb%al, 7(%rdi)
movzbl 8(%rsi), %eax
movb%al, 8(%rdi)
movzbl 9(%rsi), %eax
movb%al, 9(%rdi)
movzbl 10(%rsi), %eax
movb%al, 10(%rdi)
movzbl 11(%rsi), %eax
movb%al, 11(%rdi)
movzbl 12(%rsi), %eax
movb%al, 12(%rdi)
movzbl 13(%rsi), %eax
movb%al, 13(%rdi)
movzbl 14(%rsi), %eax
movb%al, 14(%rdi)
movzbl 15(%rsi), %eax
movb%al, 15(%rdi)
ret
.p2align 4,,10
.p2align 3
[Bug testsuite/40543] New: [4.5 Regression] FAIL: g++.dg/pch/pch.C
Between revisions 148536 and 148750 the following failures appeared: FAIL: g++.dg/pch/pch.C -g -I. (test for excess errors) FAIL: g++.dg/pch/pch.C -g assembly comparison FAIL: g++.dg/pch/pch.C -O2 -g -I. (test for excess errors) FAIL: g++.dg/pch/pch.C -O2 -g assembly comparison FAIL: g++.dg/pch/pch.C -O2 -I. (test for excess errors) FAIL: g++.dg/pch/pch.C -O2 assembly comparison The excess errors is: FAIL: g++.dg/pch/pch.C -g -I. (test for excess errors) Excess errors: /opt/gcc/gcc-4.5-work/gcc/testsuite/g++.dg/pch/pch.C:4:1: error: 'int' does not name a type -- Summary: [4.5 Regression] FAIL: g++.dg/pch/pch.C Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40543
[Bug regression/40540] Error compiling with march=atom and GCC 4.5_20090618
--- Comment #3 from hjl dot tools at gmail dot com 2009-06-24 13:20 --- (In reply to comment #0) Since my update to version 4.5 06-18-2009 i have some errors on compiling. Here are my logs for ppp-2.4.4 and xorg-server-1.6.1.901 These are my first packages after compiler update and i think many of the other packages will post the same errors. Your assembler doesn't support movbe. You can get the current Linux binutils at http://www.kernel.org/pub/linux/devel/binutils/ -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40540
[Bug testsuite/40543] [4.5 Regression] FAIL: g++.dg/pch/pch.C
--- Comment #1 from dominiq at lps dot ens dot fr 2009-06-24 13:21 --- I have forgotten to say that the failures do not appear with -m64, see http://gcc.gnu.org/ml/gcc-testresults/2009-06/msg01990.html . -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40543
[Bug testsuite/40543] [4.5 Regression] FAIL: g++.dg/pch/pch.C
--- Comment #2 from dominiq at lps dot ens dot fr 2009-06-24 13:25 --- Also forgot to say it occurs on i686-apple-darwin9 but not on powerpc-apple-darwin9. -- dominiq at lps dot ens dot fr changed: What|Removed |Added GCC build triplet||i686-apple-darwin9 GCC host triplet||i686-apple-darwin9 GCC target triplet||i686-apple-darwin9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40543
[Bug testsuite/40544] New: FAIL: gcc.dg/torture/builtin-math-6.c
Since at least revision 148536, I see the following failures on *-apple-darwin9: FAIL: gcc.dg/torture/builtin-math-6.c -O0 (test for excess errors) FAIL: gcc.dg/torture/builtin-math-6.c -O1 (test for excess errors) FAIL: gcc.dg/torture/builtin-math-6.c -O2 (test for excess errors) FAIL: gcc.dg/torture/builtin-math-6.c -O3 -fomit-frame-pointer (test for excess errors) FAIL: gcc.dg/torture/builtin-math-6.c -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) FAIL: gcc.dg/torture/builtin-math-6.c -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) FAIL: gcc.dg/torture/builtin-math-6.c -O3 -g (test for excess errors) FAIL: gcc.dg/torture/builtin-math-6.c -Os (test for excess errors) The failure is: [ibook-dhum] f90/bug% gcc45 /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/torture/builtin-math-6.c Undefined symbols: _link_error, referenced from: _main in ccCX31E2.o _main in ccCX31E2.o _main in ccCX31E2.o _main in ccCX31E2.o _main in ccCX31E2.o _main in ccCX31E2.o ld: symbol(s) not found collect2: ld returned 1 exit status -- Summary: FAIL: gcc.dg/torture/builtin-math-6.c Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr GCC build triplet: *-apple-darwin9 GCC host triplet: *-apple-darwin9 GCC target triplet: *-apple-darwin9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40544
[Bug testsuite/40531] FAIL: gcc.c-torture/execute/20090618-1.c compilation, -O0
--- Comment #1 from dominiq at lps dot ens dot fr 2009-06-24 13:36 --- Also seen on *-apple-darwin9. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40531
[Bug fortran/40539] Inversion of logical function compiled with ifort not correct.
--- Comment #3 from burnus at gcc dot gnu dot org 2009-06-24 13:45 --- I think the problem relates to what is regarded as TRUE and what is regarded as FALSE by the compilers (the following output has been produced by transfer(.true.,0), transfer(.false.,0)): gfortran has: .true. = 1, .false. = 0 iforthas: .true. = -1, .false. = 0 For print *, lsame() the libgfortran library has (int)logical_value ? 'T' : 'F' and thus all non-zero values are TRUE. However, for print *, .not.lsame() there is first a .not. applied in the produced assembler. As the logical (Bool) type is used, it is assumed that only 0 and 1 can appear as values, which makes it simpler to .NOT. the value. However, if -1 is passed .NOT. won't work. Example using print *, i,': ', transfer(i,.true.), .not.transfer(i,.true.),transfer(.not.transfer(i,.true.),0) For gfortran: 1 : T F 0 2 : T T 3 3 : T T 2 2147483647 : T T 2147483646 0 : F T 1 -1 : T T -2 -2 : T T -1 -3 : T T -4 -2147483648 : T T -2147483647 For ifort 11.1: 1 : T F -2 2 : F T -3 3 : T F -4 2147483647 : T F -2147483648 0 : F T -1 -1 : T F 0 -2 : F T 1 -3 : T F 2 -2147483648 : F T 2147483647 * * * If I use gfortran 4.2.0, the logical results are correct. I think the boolean optimization was not yet done in older GCCs; with GCC 4.1.3 it thus works. Iget .not.(-1) = 0, but with 4.2.1 I get .not.(-1) = -2 Change of Intel compiler version ( 9.1, 10.1 were tested ) doesn't affect result. For completeness, I think it also works with ifc 7.1 (i.e. ifort 8.0 / before the Compaq compiler merge). * * * Actually, both the GCC and the Intel Compiler use the same optimization regarding true/false for logical variables. For both -1 and 1 one only needs to flip a bit to go from .true. to .false. and vice verca. When using the integer check (value != 0), the assembler code becomes longer/slower. ifort uses: odd integer values (low bit one) are treated as true and even integer values (low bit zero) are treated as false. Solution: I do not see a general solution, but I am open for suggestions. On the ifort side: -fpscomp logicals fixes it, but makes the code a bit slower. I think there is no GCC flag, which forces booleans to be treated like integers. * * * GNU Fortran bug (1): Maybe one should note in the documentation somewhere the value of and problems with .true./.false. (2) One could think of getting libgfortran compatible with the boolean-handling in the middle end. -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||steven at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40539
[Bug tree-optimization/40542] [4.3/4.4/4.5 Regression] vectorizes access to volatile array
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-06-24 14:02 ---
Confirmed.
void
volarr_cpy(char *d, volatile char *s)
{
int i;
for ( i=0; i16; i++ )
d[i]=s[i];
}
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|c |tree-optimization
Ever Confirmed|0 |1
GCC build triplet|x86_64-unkown-linux |
GCC host triplet|x86_64-unknown-linux|
GCC target triplet|x86_64-unknown-linux, i386- |
|unknown-linux, i386-unknown-|
|rtems, po |
Keywords||wrong-code
Last reconfirmed|-00-00 00:00:00 |2009-06-24 14:02:05
date||
Summary|gcc-4.3.3 vectorizes access |[4.3/4.4/4.5 Regression]
|to volatile array |vectorizes access to
||volatile array
Target Milestone|--- |4.3.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40542
[Bug fortran/40545] New: compile warnings in libgfortran
libgfortran/io/write.c: In function 'nml_write_obj':
libgfortran/io/write.c:1261:17: warning: comparison between 'bt' and 'enum
anonymous'
libgfortran/io/write.c:1303:5: warning: case value '6' not in enumerated type
'bt'
libgfortran/io/write.c:1339:15: warning: comparison between 'bt' and 'enum
anonymous'
libgfortran/io/write.c:1372:6: warning: case value '6' not in enumerated type
'bt'
libgfortran/io/list_read.c: In Function nml_read_obj:
libgfortran/io/list_read.c:2345:5: Warning: case value 6 not in enumerated
type bt
libgfortran/io/list_read.c:2393:4: Warning: case value 6 not in enumerated
type bt
libgfortran/io/list_read.c:2470:31: Warning: comparison between bt and enum
anonym
libgfortran/io/list_read.c: In Function nml_get_obj_data:
libgfortran/io/list_read.c:2718:20: Warning: comparison between bt and enum
anonym
libgfortran/io/list_read.c:2740:28: Warning: comparison between bt and enum
anonym
libgfortran/io/list_read.c:2774:16: Warning: comparison between bt and enum
anonym
intrinsics/iso_c_binding.c: In Function __iso_c_binding_c_f_pointer_u0:
libgfortran/intrinsics/iso_c_binding.c:112:20: Warning: ub may be used
uninitialized in this function
Maybe one should use here:
switch(size) {
#ifdef HAVE_GFC_INTEGER_1
case 1:
...
default:
__builtin_unreachable(); /* Or through an error here. */
}
--
Summary: compile warnings in libgfortran
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
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=40545
[Bug tree-optimization/40529] ICE with -floop-block, verify_ssa failed
--- Comment #4 from spop at gcc dot gnu dot org 2009-06-24 14:22 --- (In reply to comment #3) ICEs with -O -ffast-math -floop-block: also ICEs the same way on the trunk. This is fixed in the graphite branch, although -floop-block is not available now, I tried with -floop-interchange, -floop-strip-mine and -fgraphite-identity and they all worked. I will close this bug when the graphite branch will be merged back to trunk, and that will happen as soon as we will have -floop-block back. Sebastian -- spop at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-06-24 14:22:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40529
[Bug c++/40538] Compiler crashes while using decimal float point in a function argument
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-06-24 14:45 --- Most likely the same issue as PR 39131. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||39131 Keywords||ABI, ice-on-valid-code Summary|Compiler crashes|Compiler crashes while using ||decimal float point in a ||function argument http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40538
[Bug fortran/40539] Inversion of logical function compiled with ifort not correct.
--- Comment #4 from alexander dot v dot kobotov at intel dot com 2009-06-24 15:04 --- Created an attachment (id=18059) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18059action=view) LSAME asm and object for Intel64 arch. lsame.f from reproducer compiled with Intel 9.1 Fortran compiler. An object file and assembly for Intel64 included. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40539
[Bug testsuite/40544] FAIL: gcc.dg/torture/builtin-math-6.c
--- Comment #1 from dominiq at lps dot ens dot fr 2009-06-24 15:07 --- Forgot to say that the builds were with MPC enabled. -- dominiq at lps dot ens dot fr changed: What|Removed |Added CC||ghazi at caip dot rutgers ||dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40544
[Bug c/40528] Add a new ifunc attribute
--- Comment #1 from hjl dot tools at gmail dot com 2009-06-24 15:28 --- With option 3, we can check the return value of an ifunc function since we know the return value is a pointer to the ifunc function. We don't need a separate prototype nor asm statement. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40528
[Bug c/40528] Add a new ifunc attribute
--- Comment #2 from hjl dot tools at gmail dot com 2009-06-24 15:31 --- Created an attachment (id=18060) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18060action=view) Ifunc examples Here are some ifunc examples with option 3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40528
[Bug testsuite/40544] FAIL: gcc.dg/torture/builtin-math-6.c
--- Comment #2 from ghazi at gcc dot gnu dot org 2009-06-24 15:46 --- This is a problem with mpc-0.6, fixed in the MPC svn repo. http://gcc.gnu.org/ml/gcc-patches/2009-06/msg01157.html Testing with mpc-0.6 is still useful because it exercises major changes in the fortran frontend. -- ghazi at gcc dot gnu dot org changed: What|Removed |Added CC|ghazi at caip dot rutgers |ghazi at gcc dot gnu dot org |dot edu | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40544
[Bug c/40528] Add a new ifunc attribute
--- Comment #3 from jakub at gcc dot gnu dot org 2009-06-24 15:54 ---
Option 2) is certainly the least intrusive in the compiler and you can use it
even with foo's prototype and calling it from the same CU, just use asm.
__typeof (foo) *
__attribute__ ((ifunc))
foo_ifunc (void) __asm (foo)
{
return address of foo_{1,2,3}
}
If you don't have a prototype, you can use the variant originally mentioned in
option 2). Most users will wrap this stuff in a macro anyway and in that case
whether they use just an attribute or attribute and __asm is not a big deal.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40528
[Bug c++/40342] [4.4/4.5 Regression] ambiguous overload not diagnosed
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-06-24 15:59:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40342
[Bug middle-end/37053] [4.3/4.4/4.5 regression] ICE in reload_cse_simplify_operands, at postreload.c:395
--- Comment #13 from mkuvyrkov at gcc dot gnu dot org 2009-06-24 16:02 --- Created an attachment (id=18061) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18061action=view) Proposed patch Here is a patch moving precedence handling of pointers to powerpc backend. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37053
[Bug fortran/40539] Inversion of logical function compiled with ifort not correct.
--- Comment #5 from alexander dot v dot kobotov at intel dot com 2009-06-24 16:02 --- Thanks a lot, there is indeed different values for true: For GFORTRAN: true = 1, false = 0 For Intel Fortran: true = -1, false = 0. In IF expression both true values works, but NOT operand in GFORTRAN could invert only GFORTRAN's values in 4.4.0. The real problem with the issue is that code compiled with GFORTRAN could have issues if linked with a vendor library. I'm experiencing ones with Intel#174; MKL. It would be nice to have an option to turn off that fast inversion, at least for compatibility. Or at least to make -O0 case compatible. Thanks, Alexander. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40539
[Bug c/40528] Add a new ifunc attribute
--- Comment #4 from hjl dot tools at gmail dot com 2009-06-24 16:07 ---
(In reply to comment #3)
Option 2) is certainly the least intrusive in the compiler and you can use it
even with foo's prototype and calling it from the same CU, just use asm.
__typeof (foo) *
__attribute__ ((ifunc))
foo_ifunc (void) __asm (foo)
{
return address of foo_{1,2,3}
}
If you don't have a prototype, you can use the variant originally mentioned in
option 2). Most users will wrap this stuff in a macro anyway and in that case
whether they use just an attribute or attribute and __asm is not a big deal.
I think we enforce type check on return value of ifunc function.
This is a user feature. Option 3 is the most user friendly. We
only need to change the return type to a pointer to function
prototype inside ifunc function body. I have a patch for option 3.
It isn't too bad.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40528
[Bug c++/40342] [4.4/4.5 Regression] ambiguous overload not diagnosed
--- Comment #2 from jason at gcc dot gnu dot org 2009-06-24 16:26 --- Subject: Bug 40342 Author: jason Date: Wed Jun 24 16:25:52 2009 New Revision: 148910 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=148910 Log: PR c++/40342 * decl.c (decls_match): Check DECL_TI_TEMPLATE too. * class.c (resolve_address_of_overloaded_function): Fix typo. Added: trunk/gcc/testsuite/g++.dg/template/overload10.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40342
[Bug c++/40538] Compiler crashes while using decimal float point in a function argument
--- Comment #2 from igodard at pacbell dot net 2009-06-24 16:34 --- Probably not the same as 39131, because this ices only if the function is declared. Both the typedef and the data declaration compile OK without the function, whereas 39131 seems to ice without any use at all. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40538
[Bug middle-end/40493] [4.5 Regression] New SRA miscompiled binutils
--- Comment #13 from jamborm at gcc dot gnu dot org 2009-06-24 16:38 --- Fix submitted to the mailing list, pending maintainer approval: http://gcc.gnu.org/ml/gcc-patches/2009-06/msg01918.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40493
[Bug fortran/40541] Assignment checking for proc-pointer = proc-ptr-returning-function()
--- Comment #1 from janus at gcc dot gnu dot org 2009-06-24 16:43 ---
This is easily fixed by the following patchlet (I had just forgotten about this
case):
Index: gcc/fortran/expr.c
===
--- gcc/fortran/expr.c (revision 148905)
+++ gcc/fortran/expr.c (working copy)
@@ -3189,10 +3189,14 @@
/* TODO: Enable interface check for PPCs. */
if (is_proc_ptr_comp (rvalue, NULL))
return SUCCESS;
- if (rvalue-expr_type == EXPR_VARIABLE
- !gfc_compare_interfaces (lvalue-symtree-n.sym,
- rvalue-symtree-n.sym, 0, 1, err,
- sizeof(err)))
+ if ((rvalue-expr_type == EXPR_VARIABLE
+ !gfc_compare_interfaces (lvalue-symtree-n.sym,
+ rvalue-symtree-n.sym, 0, 1, err,
+ sizeof(err)))
+ || (rvalue-expr_type == EXPR_FUNCTION
+ !gfc_compare_interfaces (lvalue-symtree-n.sym,
+ rvalue-symtree-n.sym-result, 0, 1,
+ err, sizeof(err
{
gfc_error (Interface mismatch in procedure pointer assignment
at %L: %s, rvalue-where, err);
However, there remains one problem (aka PR 39695): The error message for the
code in comment #0 has the wrong name:
p = f()
1
Error: Interface mismatch in procedure pointer assignment at (1): Type/kind
mismatch in return value of 'ppr@'
--
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|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2009-06-24 16:43:47
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40541
[Bug c++/40342] [4.4/4.5 Regression] ambiguous overload not diagnosed
--- Comment #3 from jason at gcc dot gnu dot org 2009-06-24 17:02 ---
Subject: Bug 40342
Author: jason
Date: Wed Jun 24 17:02:03 2009
New Revision: 148911
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=148911
Log:
PR c++/40342
* decl.c (decls_match): Check DECL_TI_TEMPLATE too.
* class.c (resolve_address_of_overloaded_function): Fix typo.
Added:
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/overload10.C
- copied unchanged from r148910,
trunk/gcc/testsuite/g++.dg/template/overload10.C
Modified:
branches/gcc-4_4-branch/gcc/ (props changed)
branches/gcc-4_4-branch/gcc/cp/ChangeLog
branches/gcc-4_4-branch/gcc/cp/class.c
branches/gcc-4_4-branch/gcc/cp/decl.c
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog
Propchange: branches/gcc-4_4-branch/gcc/
('svn:mergeinfo' added)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40342
[Bug c++/40342] [4.4/4.5 Regression] ambiguous overload not diagnosed
--- Comment #4 from jason at gcc dot gnu dot org 2009-06-24 17:04 --- Fixed. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40342
[Bug fortran/40539] Inversion of logical function compiled with ifort not correct.
--- Comment #6 from kargl at gcc dot gnu dot org 2009-06-24 17:23 --- (In reply to comment #5) The real problem with the issue is that code compiled with GFORTRAN could have issues if linked with a vendor library. I'm experiencing ones with Intel#174; MKL. It would be nice to have an option to turn off that fast inversion, at least for compatibility. Or at least to make -O0 case compatible. How do other vendor's (Sun, Pathscale, Absoft, etc) represent .true. and .false.? Do we need a compatibility option for each vendor? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40539
[Bug fortran/40539] Inversion of logical function compiled with ifort not correct.
--- Comment #7 from pinskia at gcc dot gnu dot org 2009-06-24 17:33 --- Wait I don't think we should support this at all because the ABI between gfortran and ifort are way different. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40539
[Bug fortran/40539] Inversion of logical function compiled with ifort not correct.
--- Comment #8 from burnus at gcc dot gnu dot org 2009-06-24 17:59 --- Alexander, I just filled Issue 553679 at premier.intel.com as associated bug. I realized that the issue is even bigger: C99's 6.3.1.2 has When any scalar value is converted to _Bool, the result is 0 if the value compares equal to 0; otherwise, the result is 1. Thus with BIND(C) and using LOGICAL(C_BOOL), the C compiler (or a Fortran compiler with C binding) can expect that .TRUE. matches 1 and can do optimizations based on this assumption. (In reply to comment #5) The real problem with the issue is that code compiled with GFORTRAN could have issues if linked with a vendor library. I'm experiencing ones with Intel MKL. It would be nice to have an option to turn off that fast inversion, at least for compatibility. Or at least to make -O0 case compatible. First, I think we agree that this is not only a gfortran - ifort but a GCC (gcc,g++,gfortran) - ifort interoperability problem. Secondly, using GCC, one can work around the problem using ! ((int) lsame()) and transfer(lsame(),0) == 0 which is quite ugly. Thirdly, one can think of an option in GCC (or only gfortran), but I think changing the behaviour for -O0 is not a good solution: Telling someone to use -O0 with MKL is not helpful and it hampers finding out what goes wrong. One thus needs to have an option which applies at all optimization levels. Fourthly, one can think about modifing ifort and how to build the MKL. (Unfortunately, I do not see a good solution for this - all are not really userfriendly.) In summary: This is a quite special but rather ugly interoperability problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40539
[Bug fortran/40539] Inversion of logical function compiled with ifort not correct.
--- Comment #9 from burnus at gcc dot gnu dot org 2009-06-24 18:11 --- It would be nice to have an option to turn off that fast inversion, at least for compatibility. Or at least to make -O0 case compatible. How do other vendor's (Sun, Pathscale, Absoft, etc) represent .true. and .false.? Do we need a compatibility option for each vendor? Well, I think handling ! boolean as ! (int) boolean is enough, i.e. converting all booleans to integer as C has for integers the concept of nonzero = true and zero = false - thus NOT(nonzero) is alway zero (all bits). I think one can consider such an option, but I am not really happy about such a solution - and I think (fear?) others will (strongly) oppose such an option. Regarding the rhetoric question: NAG f95, sunf95 and g95 use 1 and 0; using ifort + Intel's icc, open64's opencc, Sun's suncc, however, gives FALSE for when using NOT (!) on the result of the Fortran function call. (With GCC it gives TRUE.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40539
[Bug c/40528] Add a new ifunc attribute
--- Comment #5 from jakub at gcc dot gnu dot org 2009-06-24 19:26 ---
What do you do if the function has arguments, because ifunc shouldn't have
arguments? While C++ has unnamed arguments and you could perhaps enforce them,
C does not. How do you handle option 3 with:
__attribute__((ifunc)) int
foo (int a, int b)
{
if (a) return foo_1;
if (b) return foo_2;
return foo_3;
}
?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40528
[Bug c/40528] Add a new ifunc attribute
--- Comment #6 from hjl dot tools at gmail dot com 2009-06-24 19:31 ---
(In reply to comment #5)
What do you do if the function has arguments, because ifunc shouldn't have
arguments? While C++ has unnamed arguments and you could perhaps enforce
them,
For unnamed arguments, see ifunc-1.c in
http://gcc.gnu.org/bugzilla/attachment.cgi?id=18060
C does not. How do you handle option 3 with:
__attribute__((ifunc)) int
foo (int a, int b)
{
if (a) return foo_1;
if (b) return foo_2;
return foo_3;
}
?
[...@gnu-6 examples]$ cat x.c
int foo_1 (int, int);
int foo_2 (int, int);
int foo_3 (int, int);
__attribute__((ifunc)) int
foo (int a, int b)
{
if (a) return foo_1;
if (b) return foo_2;
return foo_3;
}
[...@gnu-6 examples]$ make x.s
/export/build/gnu/gcc-work/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-work/build-x86_64-linux/gcc/ -S -o x.s -O2 -Wall
-Wextra x.c
x.c: In function foo:
x.c:6:1: error: parameter a used in indirect function foo
x.c:6:1: error: parameter b used in indirect function foo
make: *** [x.s] Error 1
[...@gnu-6 examples]$
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40528
[Bug fortran/39997] Procedure(), pointer implicit typing: rejects-valid / accepts-invalid?
--- Comment #5 from burnus at gcc dot gnu dot org 2009-06-24 21:53 --- Created an attachment (id=18062) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18062action=view) Initial patch, somewhat working, but still many failures Draft patch for item 1 and item 2 - still incomplete. Implicit typing of PPC: Not (planed to be) covered by this patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39997
[Bug c/39878] gcc 4.3.2 converts Decimal FP constants wrong
--- Comment #1 from janis at gcc dot gnu dot org 2009-06-24 22:03 --- GCC defines DEC_EVAL_METHOD to be 0: evaluate all operations just to the range and precision of the type. The arithmetic/comparison/conversion functions in libgcc (for DPD, not sure about BID) use the range and precision of the type, which matches 0. Except for compile-time constants, use of hardware DFP support for POWER6 matches 1: evaluate operations [and constants] of type _Decimal32 and _Decimal64 to the range and precision of the _Decimal64 type, evaluate _Decimal128 operations [and constants] to the range and precision of the _Decimal128 type. Within the compiler, decimal float constants are evaluated and folded using 128-bit precision, which matches 2: evaluate all operations and constants to the range and precision of the _Decimal128 type. We could cop out and set DEC_EVAL_METHOD to -1 (indeterminable) but it would be better to pick one of the other values and honor it consistently. -- janis at gcc dot gnu dot org changed: What|Removed |Added CC||bje at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39878
[Bug middle-end/40547] New: comparison in lhs of ?: incorrectly converted to unsigned min
Compiling this test program with gcc-4.4-20090623 fails with a linker error:
cat pr39867-redux.c
int main (void)
{
int exp = -1;
/* Wrong folding of the LHS to an unsigned MIN leads to 2 != 4294967295. */
if ((exp 2 ? (unsigned int) exp : 2U) != -1U)
link_error ();
return 0;
}
gcc -O2 pr39867-redux.c
/tmp/ccwtpmSD.o: In function `main':
pr39867-redux.c:(.text+0x7): undefined reference to `link_error'
collect2: ld returned 1 exit status
This is a regression from gcc-4.3.3 and earlier releases.
The test case is a variant of PR39867, which got fixed. That bug report was
about fold-const.c turning a ?: into MAX and wrongly changing a signed compare
to an unsigned compare in the process. There are additional cases that turn ?:
into MIN, but they weren't considered or fixed.
I'll attach the test case and a proposed fix.
--
Summary: comparison in lhs of ?: incorrectly converted to
unsigned min
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mikpe at it dot uu dot se
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40547
[Bug middle-end/40547] comparison in lhs of ?: incorrectly converted to unsigned min
--- Comment #1 from mikpe at it dot uu dot se 2009-06-24 22:25 --- Created an attachment (id=18063) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18063action=view) test case test case illustrating the bug -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40547
[Bug middle-end/40547] comparison in lhs of ?: incorrectly converted to unsigned min
--- Comment #2 from mikpe at it dot uu dot se 2009-06-24 22:29 --- Created an attachment (id=18064) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18064action=view) proposed patch fixing this error This patch adapts Paolo Bonzini's patch for PR39867 to handle the remaining two cases in fold_cond_expr_with_comparison that produce MIN rather than MAX. Bootstrapped on i686-pc-linux-gnu and verified to fix the test case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40547
[Bug target/37750] a lot of crashes with tree optimizations on mingw
--- Comment #12 from sherpya at netfarm dot it 2009-06-24 23:22 --- however 4.5 is still far from being stable as 4.2, I get many crashes while using complied mplayer (it's a stress test for gcc :)) Unfortunately I had no much time to debug mplayer builds -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37750
[Bug c/40548] New: If a dir on PATH contains a directory named gcc, badness ensues
I have a directory on my PATH that contains a subdirectory named gcc. When I run gcc (not fully-qualified) I get all sorts of very bizarre behavior. For example: $ cat t.c #include limits.h $ mkdir gcc $ PATH=.:$PATH gcc -E t.c /dev/null In file included from /tmp/t.c:1: /usr/include/limits.h:125:26: error: no include path in which to search for limits.h But, if I don't have a local directory gcc then all is fine: $ rmdir gcc $ PATH=.:$PATH gcc -E t.c /dev/null $ If I use a fully-qualified path for GCC (/usr/bin/gcc) then it also does not fail. It looks to me like the test GCC performs when looking for itself through PATH just checks for executability (if I have a non-executable file in a directory on PATH this doesn't happen) but doesn't check for directory-ness. This is wrong, because the shell's PATH search algorithm DOES check for directory-ness and skips directories that appear in directories on your PATH. -- Summary: If a dir on PATH contains a directory named gcc, badness ensues Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: psmith at gnu dot org GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40548
[Bug target/40503] DEC_EVAL_METHOD not match operators
--- Comment #1 from hjl dot tools at gmail dot com 2009-06-25 00:15 --- Can you provide a testcase? -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40503
[Bug testsuite/40532] FAIL: gcc.dg/builtins-65.c (test for excess errors)
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2009-06-25 00:32 --- Subject: Re: FAIL: gcc.dg/builtins-65.c (test for excess errors) Can you put HAVE_C99_RUNTIME around problematic conversions (just copy the approach from builtins-18.c) ? Attached diff. However, there's still a call left to linK_error. Attached builtins-65.c.133t.optimized. Dave --- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2009-06-25 00:32 --- Created an attachment (id=18065) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18065action=view) --- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2009-06-25 00:32 --- Created an attachment (id=18066) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18066action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40532
[Bug c/40548] If a dir on PATH contains a directory named gcc, badness ensues
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-06-25 01:25 --- *** This bug has been marked as a duplicate of 38966 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40548
[Bug other/38966] libiberty make_relative_prefix_1 mistakes directories for executables
--- Comment #8 from pinskia at gcc dot gnu dot org 2009-06-25 01:25 --- *** Bug 40548 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||psmith at gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38966
[Bug bootstrap/40511] Bootstrap Failure in stage3: c++locale - Recent SVN
--- Comment #8 from mckelvey at maskull dot com 2009-06-25 01:52 --- I was able to build with --enable-clocale=generic. Thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40511
[Bug target/40515] SH: m2a* options not docmented.
--- Comment #4 from kkojima at gcc dot gnu dot org 2009-06-25 04:39 --- Fixed. -- kkojima at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40515
[Bug c/40548] If a dir on PATH contains a directory named gcc, badness ensues
--- Comment #2 from psmith at gnu dot org 2009-06-25 05:00 --- Ah, thanks for the pointer. I did search before I created a new bug but wasn't successful in narrowing down my search to something reasonable. It would be nice if the real bug mentioned PATH in the summary; I was trying to use case-sensitive searches for PATH but searching comments turned up 150 bugs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40548
