[Bug target/43129] New: Simplify global variable's address loading with option -fpic
Compile the following code with options -march=armv5te -mthumb -Os -fpic
extern int i;
int foo(int j)
{
int t = i;
i = j;
return t;
}
GCC generates following code:
foo:
ldr r3, .L2// A
ldr r2, .L2+4 // B
.LPIC0:
add r3, pc // A
ldr r3, [r3, r2] // B
@ sp needed for prologue
ldr r2, [r3]
str r0, [r3]
mov r0, r2
bx lr
.L3:
.align 2
.L2:
.word _GLOBAL_OFFSET_TABLE_-(.LPIC0+4) // A
.word i(GOT) // B
Instructions marked A compute the address of GOT table, instructions marked B
load the global variables GOT entry to get actual address of the global
variable. There are 4 instructions and 2 constant pool entries in total. It can
be simplified by applying the fact that the offset from label .LPIC0 to any GOT
entry is fixed at linking time. The result is:
foo:
ldr r3, .L2// C
.LPIC0:
add r3, pc // C
ldr r3, [r3] // C
@ sp needed for prologue
ldr r2, [r3]
str r0, [r3]
mov r0, r2
bx lr
.L3:
.align 2
.L2:
.word ABS_ADDRESS_OF_GOT_ENTRY_FOR_i -(.LPIC0+4) // C
The instructions marked C load the actual address of a global variable. It uses
only 3 instructions and 1 constant pool entry. It is both smaller and faster.
But it is not always beneficial to use instruction sequence C. If there are
many global variable accesses, by using code sequence B, each one global
variable need 2 extra instructions to load its address. But using code sequence
C, each one global variable need 3 extra instructions to load its address.
Suppose there are n global variables, the code size needed to compute the
actual addresses by instruction sequence A and B is:
code_size(A) + code_size(B) * n = 2*2 + 4 + (2*2 + 4) * n = 8n + 8 <1>
The code size needed by instruction sequence C is:
code_size(C) = (3*2 + 4) * n = 10n <2>
Let <1> = <2>, we get
8n + 8 = 10n
n = 4
So if there are more than 4 global variables' access instruction sequence A and
B is smaller, if there are less than 4 global variables' access instruction
sequence C is smaller. If there are 4 global variables' access both methods
have same code size. But code sequence C has one less memory load (the load in
instructions A) and use one less register(the global register hold the GOT
address). So code sequence C is still faster.
For arm instruction set, both methods have same code sequence, but with
different code size, now we have
4 * 2 + 4 + (4 * 2 + 4) * n = (4 * 3 + 4) * n
n = 3
So the threshold value of n is 3 for arm instruction set.
Now the problem is how to represent the offset from a code label to a global
variable's GOT entry. Ian mentioned that arm relocation R_ARM_GOT_PREL can be
used, but I can't find how to represent this relocation in gnu assembler.
Any suggestions?
--
Summary: Simplify global variable's address loading with option -
fpic
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carrot at google dot com
GCC build triplet: i686-linux
GCC host triplet: i686-linux
GCC target triplet: arm-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43129
[Bug fortran/42958] Weird temporary array allocation
--- Comment #6 from burnus at gcc dot gnu dot org 2010-02-20 08:31 --- Subject: Bug 42958 Author: burnus Date: Sat Feb 20 08:31:25 2010 New Revision: 156923 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156923 Log: 2010-02-20 Tobias Burnus PR fortran/42958 * libgfortran.h: Add GFC_RTCHECK_MEM. * invoke.texi (-fcheck=): Document -fcheck=mem. * tranc.c (gfc_call_malloc): Remove negative-size run-time error and enable malloc-success check only with -fcheck=mem. * option.c (gfc_handle_runtime_check_option): Add -fcheck=mem. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/invoke.texi trunk/gcc/fortran/libgfortran.h trunk/gcc/fortran/options.c trunk/gcc/fortran/trans.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42958
Re: [Bug c++/43126] "at this point in file" warnings are upside down
Sent from my iPhone
On Feb 19, 2010, at 10:51 PM, "glenn at zewt dot org" > wrote:
--- Comment #3 from glenn at zewt dot org 2010-02-20 06:51
---
("4:16"? I havn't seen that before. I hope gcc isn't going to start
outputting character offsets by default; that's a lot of noise.)
Yes gcc is now printing out column information. And no it is not a lot
of noise.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43126
[Bug c++/43126] "at this point in file" warnings are upside down
--- Comment #4 from pinskia at gmail dot com 2010-02-20 09:00 ---
Subject: Re: "at this point in file" warnings are upside down
Sent from my iPhone
On Feb 19, 2010, at 10:51 PM, "glenn at zewt dot org" wrote:
>
>
> --- Comment #3 from glenn at zewt dot org 2010-02-20 06:51
> ---
> ("4:16"? I havn't seen that before. I hope gcc isn't going to start
> outputting character offsets by default; that's a lot of noise.)
Yes gcc is now printing out column information. And no it is not a lot
of noise.
>
>
> --
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43126
>
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43126
[Bug target/43047] internal compiler error: in extract_insn, at recog.c:2048
--- Comment #12 from danny dot backx at scarlet dot be 2010-02-20 09:55 --- Re: comments #9, 11 I don't understand this comment. Is it a simple observation, or should I be able to draw conclusions about the origin of the problem from this? Re: comment #10 I don't know whether this occurs on older versions of gcc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43047
[Bug c/43128] c-c++-common/pr41779.c doesn't work
--- Comment #1 from manu at gcc dot gnu dot org 2010-02-20 10:40 --- What are the excess messages? -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-02-20 10:40:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43128
Re: [Bug c/43128] c-c++-common/pr41779.c doesn't work
Sent from my iPhone On Feb 20, 2010, at 2:40 AM, "manu at gcc dot gnu dot org" > wrote: --- Comment #1 from manu at gcc dot gnu dot org 2010-02-20 10:40 --- What are the excess messages? The problem is simple c does nit have overloaded functions. I am testing the obvious patch which fixes this; renaming the functions. -- manu at gcc dot gnu dot org changed: What|Removed |Added --- --- -- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-02-20 10:40:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43128
[Bug c/43128] c-c++-common/pr41779.c doesn't work
--- Comment #2 from pinskia at gmail dot com 2010-02-20 11:00 --- Subject: Re: c-c++-common/pr41779.c doesn't work Sent from my iPhone On Feb 20, 2010, at 2:40 AM, "manu at gcc dot gnu dot org" wrote: > > > --- Comment #1 from manu at gcc dot gnu dot org 2010-02-20 > 10:40 --- > What are the excess messages? The problem is simple c does nit have overloaded functions. I am testing the obvious patch which fixes this; renaming the functions. > > > -- > > manu at gcc dot gnu dot org changed: > > What|Removed |Added > --- > --- > -- > Status|UNCONFIRMED |NEW > Ever Confirmed|0 |1 > Last reconfirmed|-00-00 00:00:00 |2010-02-20 10:40:49 > date|| > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43128 > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43128
[Bug target/43047] internal compiler error: in extract_insn, at recog.c:2048
--- Comment #13 from steven at gcc dot gnu dot org 2010-02-20 11:14 --- We're using bugzilla to share what we find in our efforts to debug your problem. So it is observations. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43047
[Bug c/43128] c-c++-common/pr41779.c doesn't work
--- Comment #3 from manu at gcc dot gnu dot org 2010-02-20 11:51 --- Subject: Bug 43128 Author: manu Date: Sat Feb 20 11:51:02 2010 New Revision: 156924 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156924 Log: 2010-02-20 Manuel López-Ibáñez PR 43128 * c-c++-common/pr41779.c: Fix broken testcase. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/pr41779.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43128
[Bug c/43128] c-c++-common/pr41779.c doesn't work
--- Comment #4 from manu at gcc dot gnu dot org 2010-02-20 11:51 --- Andrew, Sorry I read your message after hitting commit! Is it fixed now? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43128
[Bug target/43129] Simplify global variable's address loading with option -fpic
-- steven at gcc dot gnu dot org changed: What|Removed |Added CC||rearnsha at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-02-20 12:41:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43129
[Bug fortran/43111] [4.5 Regression] No temporary produced for array pointer actual arguments
--- Comment #3 from pault at gcc dot gnu dot org 2010-02-20 12:47 --- Subject: Bug 43111 Author: pault Date: Sat Feb 20 12:46:43 2010 New Revision: 156926 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156926 Log: 2010-02-20 Paul Thomas PR fortran/36932 PR fortran/36933 PR fortran/43072 PR fortran/43111 * dependency.c (gfc_check_argument_var_dependency): Use enum value instead of arithmetic vaue for 'elemental'. (check_data_pointer_types): New function. (gfc_check_dependency): Call check_data_pointer_types. * trans-array.h : Change fourth argument of gfc_conv_array_parameter to boolean. * trans-array.c (gfc_conv_array_parameter): A contiguous array can be a dummy but it must not be assumed shape or deferred. Change fourth argument to boolean. Array constructor exprs will always be contiguous and do not need packing and unpacking. * trans-expr.c (gfc_conv_procedure_call): Clean up some white space and change fourth argument of gfc_conv_array_parameter to boolean. (gfc_trans_arrayfunc_assign): Change fourth argument of gfc_conv_array_parameter to boolean. * trans-io.c (gfc_convert_array_to_string): The same. * trans-intrinsic.c (gfc_conv_intrinsic_loc): The same. 2010-02-20 Paul Thomas PR fortran/36932 PR fortran/36933 * gfortran.dg/dependency_26.f90: New test. PR fortran/43072 * gfortran.dg/internal_pack_7.f90: New test. PR fortran/43111 * gfortran.dg/internal_pack_8.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/dependency_26.f90 trunk/gcc/testsuite/gfortran.dg/internal_pack_7.f90 trunk/gcc/testsuite/gfortran.dg/internal_pack_8.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/dependency.c trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-array.h trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans-intrinsic.c trunk/gcc/fortran/trans-io.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43111
[Bug fortran/43072] unneeded temporary (s=s+f(a))
--- Comment #4 from pault at gcc dot gnu dot org 2010-02-20 12:47 --- Subject: Bug 43072 Author: pault Date: Sat Feb 20 12:46:43 2010 New Revision: 156926 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156926 Log: 2010-02-20 Paul Thomas PR fortran/36932 PR fortran/36933 PR fortran/43072 PR fortran/43111 * dependency.c (gfc_check_argument_var_dependency): Use enum value instead of arithmetic vaue for 'elemental'. (check_data_pointer_types): New function. (gfc_check_dependency): Call check_data_pointer_types. * trans-array.h : Change fourth argument of gfc_conv_array_parameter to boolean. * trans-array.c (gfc_conv_array_parameter): A contiguous array can be a dummy but it must not be assumed shape or deferred. Change fourth argument to boolean. Array constructor exprs will always be contiguous and do not need packing and unpacking. * trans-expr.c (gfc_conv_procedure_call): Clean up some white space and change fourth argument of gfc_conv_array_parameter to boolean. (gfc_trans_arrayfunc_assign): Change fourth argument of gfc_conv_array_parameter to boolean. * trans-io.c (gfc_convert_array_to_string): The same. * trans-intrinsic.c (gfc_conv_intrinsic_loc): The same. 2010-02-20 Paul Thomas PR fortran/36932 PR fortran/36933 * gfortran.dg/dependency_26.f90: New test. PR fortran/43072 * gfortran.dg/internal_pack_7.f90: New test. PR fortran/43111 * gfortran.dg/internal_pack_8.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/dependency_26.f90 trunk/gcc/testsuite/gfortran.dg/internal_pack_7.f90 trunk/gcc/testsuite/gfortran.dg/internal_pack_8.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/dependency.c trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-array.h trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans-intrinsic.c trunk/gcc/fortran/trans-io.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43072
[Bug fortran/36932] unneeded temporary (2x)
--- Comment #12 from pault at gcc dot gnu dot org 2010-02-20 12:47 --- Subject: Bug 36932 Author: pault Date: Sat Feb 20 12:46:43 2010 New Revision: 156926 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156926 Log: 2010-02-20 Paul Thomas PR fortran/36932 PR fortran/36933 PR fortran/43072 PR fortran/43111 * dependency.c (gfc_check_argument_var_dependency): Use enum value instead of arithmetic vaue for 'elemental'. (check_data_pointer_types): New function. (gfc_check_dependency): Call check_data_pointer_types. * trans-array.h : Change fourth argument of gfc_conv_array_parameter to boolean. * trans-array.c (gfc_conv_array_parameter): A contiguous array can be a dummy but it must not be assumed shape or deferred. Change fourth argument to boolean. Array constructor exprs will always be contiguous and do not need packing and unpacking. * trans-expr.c (gfc_conv_procedure_call): Clean up some white space and change fourth argument of gfc_conv_array_parameter to boolean. (gfc_trans_arrayfunc_assign): Change fourth argument of gfc_conv_array_parameter to boolean. * trans-io.c (gfc_convert_array_to_string): The same. * trans-intrinsic.c (gfc_conv_intrinsic_loc): The same. 2010-02-20 Paul Thomas PR fortran/36932 PR fortran/36933 * gfortran.dg/dependency_26.f90: New test. PR fortran/43072 * gfortran.dg/internal_pack_7.f90: New test. PR fortran/43111 * gfortran.dg/internal_pack_8.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/dependency_26.f90 trunk/gcc/testsuite/gfortran.dg/internal_pack_7.f90 trunk/gcc/testsuite/gfortran.dg/internal_pack_8.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/dependency.c trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-array.h trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans-intrinsic.c trunk/gcc/fortran/trans-io.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36932
[Bug fortran/36933] unneeded temporary with derived type containing an array as argument
--- Comment #8 from pault at gcc dot gnu dot org 2010-02-20 12:47 --- Subject: Bug 36933 Author: pault Date: Sat Feb 20 12:46:43 2010 New Revision: 156926 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156926 Log: 2010-02-20 Paul Thomas PR fortran/36932 PR fortran/36933 PR fortran/43072 PR fortran/43111 * dependency.c (gfc_check_argument_var_dependency): Use enum value instead of arithmetic vaue for 'elemental'. (check_data_pointer_types): New function. (gfc_check_dependency): Call check_data_pointer_types. * trans-array.h : Change fourth argument of gfc_conv_array_parameter to boolean. * trans-array.c (gfc_conv_array_parameter): A contiguous array can be a dummy but it must not be assumed shape or deferred. Change fourth argument to boolean. Array constructor exprs will always be contiguous and do not need packing and unpacking. * trans-expr.c (gfc_conv_procedure_call): Clean up some white space and change fourth argument of gfc_conv_array_parameter to boolean. (gfc_trans_arrayfunc_assign): Change fourth argument of gfc_conv_array_parameter to boolean. * trans-io.c (gfc_convert_array_to_string): The same. * trans-intrinsic.c (gfc_conv_intrinsic_loc): The same. 2010-02-20 Paul Thomas PR fortran/36932 PR fortran/36933 * gfortran.dg/dependency_26.f90: New test. PR fortran/43072 * gfortran.dg/internal_pack_7.f90: New test. PR fortran/43111 * gfortran.dg/internal_pack_8.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/dependency_26.f90 trunk/gcc/testsuite/gfortran.dg/internal_pack_7.f90 trunk/gcc/testsuite/gfortran.dg/internal_pack_8.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/dependency.c trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-array.h trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans-intrinsic.c trunk/gcc/fortran/trans-io.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36933
[Bug fortran/43111] [4.5 Regression] No temporary produced for array pointer actual arguments
--- Comment #4 from pault at gcc dot gnu dot org 2010-02-20 12:47 --- Fixed. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43111
[Bug c/43128] c-c++-common/pr41779.c doesn't work
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-02-20 13:52 --- 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=43128
[Bug c++/43127] Inconsistent and odd constructor calls.
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-02-20 14:00 ---
You can even use
virtual ptr clone () const
{
return new object(*this);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43127
[Bug middle-end/41674] [4.5 Regression] /usr/ccs/bin/ld: Unsatisfied symbols: _GLOBAL__I_65535_0_main
--- Comment #11 from rguenth at gcc dot gnu dot org 2010-02-20 14:03 --- Are they marked as DECL_PRESERVED_P? No, they are not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41674
[Bug middle-end/39315] Unaligned move used on aligned stack variable
--- Comment #14 from rguenth at gcc dot gnu dot org 2010-02-20 14:08 --- On trunk I get: foo: subl$44, %esp movl48(%esp), %eax movaps (%eax), %xmm0 leal16(%esp), %eax movl%eax, (%esp) movaps %xmm0, 16(%esp) callbar addl$44, %esp ret thus, fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work||4.5.0 Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39315
[Bug bootstrap/43121] [4.5 regression] Bootstrap failure
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-02-20 14:28 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43121
[Bug c++/43126] "at this point in file" warnings are upside down
--- Comment #5 from manu at gcc dot gnu dot org 2010-02-20 15:31 ---
(In reply to comment #3)
> ("4:16"? I havn't seen that before. I hope gcc isn't going to start
> outputting character offsets by default; that's a lot of noise.)
>
>From GCC 4.5, you can disable it with -fno-show-column.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
CC||manu at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43126
[Bug c/43128] c-c++-common/pr41779.c doesn't work
--- Comment #6 from hjl dot tools at gmail dot com 2010-02-20 15:53 --- On Linux/ia32, I still got Executing on host: /export/gnu/import/svn/gcc-test/bld/gcc/xgcc -B/export/gnu/import/svn/gcc-test/bld/gcc/ /export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/c-c++-common/pr41779.c -Wc++-compat -std=c99 -Wconversion -S -o pr41779.s(timeout = 300) FAIL: c-c++-common/pr41779.c -Wc++-compat (test for warnings, line 30) PASS: c-c++-common/pr41779.c -Wc++-compat (test for excess errors) It may be an ILP32/32bit HW INT issue. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43128
[Bug c++/43126] "at this point in file" warnings are upside down
--- Comment #6 from manu at gcc dot gnu dot org 2010-02-20 15:56 --- I have a patch. -- manu at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |manu at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2010-02-20 06:25:29 |2010-02-20 15:56:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43126
[Bug other/43130] New: GCC is not recognizing command line option "-mdynamic-no-pic" on Mac OS X 10.6 (x86_64)
Hi all. When I compile gcc-4.4.3 on Mac OS X 10.6 (x86_64) with this configuration: ./configure --prefix=/usr/local/openseeslib/gcc/4.4.3/ --enable-languages=c,c++,objc,obj-c++,fortran --with-gmp=/usr/local/openseeslib/gmp/4.3.2/ --with-mpfr=/usr/local/openseeslib/mpfr/2.4.2/ --build=x86_64-apple-darwin10 --host=x86_64-apple-darwin10 --target=x86_64-apple-darwin10 gcc will not recognize command line option "-mdynamic-no-pic". I mean, I am getting this error after trying to compile a program: cc1: error: unrecognized command line option "-mdynamic-no-pic" The default gcc (the one that comes with the OS, version 4.2.1) was configured with: /var/tmp/gcc/gcc-5646.1~2/src/configure --disable-checking --enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin10 --with-gxx-include-dir=/include/c++/4.2.1 --program-prefix=i686-apple-darwin10- --host=x86_64-apple-darwin10 --target=i686-apple-darwin10 and it is able to recognize "-mdynamic-no-pic". I do not understand why "-mdynamic-no-pic" is not available in my gcc version when I actually used a configuration similar to the one used by Apple. I am guessing that Apple ran a modified gcc version to get this option available, does not it? In such a case, any idea how to get "-mdynamic-no-pic" in my gcc-4.4.3? Thank you! PS: About my computer: MacBook (3.1), Intel Core 2 Duo, Mac OS X 10.6.2 (Snow Leopard). -- Summary: GCC is not recognizing command line option "-mdynamic- no-pic" on Mac OS X 10.6 (x86_64) Product: gcc Version: 4.4.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hresquiveloa at gmail dot com GCC build triplet: x86_64-apple-darwin10 GCC host triplet: x86_64-apple-darwin10 GCC target triplet: x86_64-apple-darwin10 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43130
[Bug target/43130] GCC is not recognizing command line option "-mdynamic-no-pic" on Mac OS X 10.6 (x86_64)
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-02-20 16:23 --- Yes have Apple submit their patches for -mdynamic-no-pic for x86_64. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|other |target Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43130
[Bug fortran/43115] bug with gfortran on Windows vista, correct on Linux
--- Comment #10 from cgerdy at wanadoo dot fr 2010-02-20 16:24 --- Subject: Re: bug with gfortran on Windows vista, correct on Linux I made a new test with an older version of gfortran I had download on your Internet page for Windows : http://gcc.gnu.org/wiki/GFortranBinaries and on that page : installer It is the only possibility for somebody which is outside of gnu to download gfortran for Windows, and by : gfortran -v, I obtain the version : it was the older 4.2.0 version. It is necessary to modify my program to test the bug because this older version do not know the line : use iso_fortran_env but and it is important, after that : This older version of gfortran have not this bug. So go to the http://gcc.gnu.org/wiki/GFortranBinaries download gfortran and test the bug After that the question for you is : where is the file in this page inside gnu and make the correction. Thank you Claude - Original Message - From: "jvdelisle at gcc dot gnu dot org" To: Sent: Friday, February 19, 2010 7:56 PM Subject: [Bug fortran/43115] bug with gfortran on Windows vista, correct on Linux > > > > --- Comment #8 from jvdelisle at gcc dot gnu dot org 2010-02-19 > 18:56 --- > If the date is correct, it is an older version. > > At the command line just type: gfortran -v > > gfortran will then display the version information for you. > > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43115 > > --- You are receiving this mail because: --- > You reported the bug, or are watching the reporter. > > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43115
[Bug other/43130] GCC is not recognizing command line option "-mdynamic-no-pic" on Mac OS X 10.6 (x86_64)
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-02-20 16:24 --- This is a powerpc-only option. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Component|target |other http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43130
[Bug other/43130] GCC is not recognizing command line option "-mdynamic-no-pic" on Mac OS X 10.6 (x86_64)
--- Comment #3 from hresquiveloa at gmail dot com 2010-02-20 16:58 --- Thanks Andrew and Richard for your quick reply. If this is a powerpc-only option, why I can successfully compile the program on x86_64 by using the default gcc? Ok... the program I am trying to compile is Tcl-8.5.8 via unix folder (because I do not like the way how tcl is installed in my computer via macosx folder... it creates a framework and I do not want that). It seems that according what you are telling me I just cannot use "-mdynamic-no-pic" option with the gcc source code. I have to modify it, but how? is this a complex task? if so, I will try to modify the tcl makefile.inc. Any suggestion/help will be greatly appreciated for both gcc and tcl. Thank you! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43130
[Bug other/43130] GCC is not recognizing command line option "-mdynamic-no-pic" on Mac OS X 10.6 (x86_64)
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-02-20 17:05 --- As I mentioned Apple has not contributed the option support back to the FSF for x86_64-darwin yet. For TCL building, you might want to go and ask the TCL folks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43130
[Bug other/43130] GCC is not recognizing command line option "-mdynamic-no-pic" on Mac OS X 10.6 (x86_64)
--- Comment #5 from hresquiveloa at gmail dot com 2010-02-20 17:07 --- Ok Thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43130
[Bug middle-end/43125] [4.5 Regression] Revision 156907 failed gcc.dg/attr-used.c
--- Comment #3 from mrs at gcc dot gnu dot org 2010-02-20 17:28 --- Subject: Bug 43125 Author: mrs Date: Sat Feb 20 17:28:14 2010 New Revision: 156927 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156927 Log: PR middle-end/43125 * c-decl.c (merge_decls): Merge DECL_PRESERVE_P. Modified: trunk/gcc/ChangeLog trunk/gcc/c-decl.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43125
[Bug other/25698] installation fails
--- Comment #2 from manu at gcc dot gnu dot org 2010-02-20 17:56 --- This bug is too old, too vague and probably fixed. -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25698
[Bug rtl-optimization/39077] [4.3/4.4/4.5 Regression] GCSE-optimization causes enormous binary size increase (~20 times !)
--- Comment #16 from steven at gcc dot gnu dot org 2010-02-20 17:58 --- Finally (!) posted the patch... -- steven at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2010- ||02/msg00824.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39077
[Bug c++/43127] Inconsistent and odd constructor calls.
--- Comment #2 from stvwooddell at embarqmail dot com 2010-02-20 18:01
---
This compiles for you?
virtual ptr clone () const
{
return new object(*this);
}
gives me the error that a function matching the copy constructor does not
exist:
n file included from ../objects/map.cpp:27:
../objects/../include/object.hpp: In member function virtual auto_ptr
object::clone() const:
../objects/../include/object.hpp:80: error: no matching function for call to
auto_ptr::auto_ptr(auto_ptr)
../objects/../include/global.hpp:73: note: candidates are:
auto_ptr::auto_ptr(auto_ptr&) [with type = object]
../objects/../include/global.hpp:71: note:
auto_ptr::auto_ptr(type*) [with type = object]
make: *** [objects/map.o] Error 1
It is my understanding that all the forms should work by creating a (anonymous)
object, then call the copy constructor passing that object as it's only
argument.
In what gcc version or configuration does it work?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43127
[Bug c++/43127] Inconsistent and odd constructor calls.
--- Comment #3 from stvwooddell at embarqmail dot com 2010-02-20 18:13 --- Scratch that, that's a error from a file that shouldn't even exist. Copied the given code to a clean project and it compiled. So bug, but a miscommunication in that the constructor is being implicitly add so that the original form is trying to pass a anonymous object as a argument to the implicitly added constructor, which is calling the protected typecast operator. Still, that leaves the issue that the following has two different behaviours when they are logically the same. I'm sure this is just a failure on my part to understand the standard, where is that covered? ptr Ret(new object(*this)); return Ret; return Ret(new object(*this)); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43127
[Bug c++/28584] Cast to pointer from integer of different size
--- Comment #2 from manu at gcc dot gnu dot org 2010-02-20 18:19 ---
Jason, do we want this?
It seems trivial:
Index: gcc/cp/typeck.c
===
--- gcc/cp/typeck.c (revision 156923)
+++ gcc/cp/typeck.c (working copy)
@@ -6260,10 +6260,20 @@ cp_build_c_cast (tree type, tree expr, t
if (complain & tf_error)
error ("invalid cast to function type %qT", type);
return error_mark_node;
}
+
+ if (TREE_CODE (type) == POINTER_TYPE
+ && TREE_CODE (TREE_TYPE (value)) == INTEGER_TYPE
+ && TYPE_PRECISION (type) != TYPE_PRECISION (TREE_TYPE (value))
+ /* Don't warn about converting any constant. */
+ && !TREE_CONSTANT (value))
+warning_at (loc,
+ OPT_Wint_to_pointer_cast, "cast to pointer from integer "
+ "of different size");
+
/* A C-style cast can be a const_cast. */
result = build_const_cast_1 (type, value, /*complain=*/false,
&valid_p);
if (valid_p)
return result;
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
CC||jason at redhat dot com,
||manu at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28584
[Bug c++/31158] wrong line number in warning: overflow in implicit constant conversion
--- Comment #2 from manu at gcc dot gnu dot org 2010-02-20 18:35 --- This is confirmed in C and C++. The front-ends need location information everywhere. Any help is appreciated. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-02-20 18:35:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31158
[Bug c/31524] prints incorrect warning
--- Comment #1 from manu at gcc dot gnu dot org 2010-02-20 18:47 --- You are using an assignment as a truth value and that is a typical error when ones confuses == with =, so we warn. Add parenthesis as the warning suggest bool = (nobool = value) or silence the warning with the appropriate -Wno-option. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31524
[Bug c++/31757] Name arguments in warnings when their names are known
--- Comment #2 from manu at gcc dot gnu dot org 2010-02-20 18:59 --- Unfortunately, I have to agree with Wolfgang. We could do better with caret diagnostics but that is still far away. Sorry, closing as WONTFIX. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31757
[Bug c++/28584] Cast to pointer from integer of different size
--- Comment #3 from jason at redhat dot com 2010-02-20 20:15 --- Subject: Re: Cast to pointer from integer of different size On 02/20/2010 01:19 PM, manu at gcc dot gnu dot org wrote: > Jason, do we want this? Sure. Jason -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28584
[Bug c++/35669] NULL (__null) not considered different from 0 with C++
--- Comment #26 from manu at gcc dot gnu dot org 2010-02-20 21:32 ---
Subject: Bug 35669
Author: manu
Date: Sat Feb 20 21:32:06 2010
New Revision: 156928
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156928
Log:
2010-02-20 Manuel López-Ibáñez
PR c++/35669
* c.opt (Wconversion-null): New option.
* doc/invoke.texi (Wconversion-null): Document.
cp/
* call.c (conversion_null_warnings): Replace -Wconversion with
-Wconversion-null.
* cvt.c (build_expr_type_conversion): Likewise.
testsuite/
* g++.dg/warn/Wconversion2.C: Replace -Wconversion with
-Wconversion-null.
* g++.dg/warn/Wconversion-null.C: New test.
* g++.old-deja/g++.other/null1.C: Move to...
* g++.dg/warn/Wconversion-null-2.C: ... here. Remove -Wconversion.
libstdc++-v3/
* testsuite/18_support/headers/cstddef/macros.cc: Add
-Wno-conversion-null.
Added:
trunk/gcc/testsuite/g++.dg/warn/Wconversion-null-2.C (contents, props
changed)
- copied, changed from r156925,
trunk/gcc/testsuite/g++.old-deja/g++.other/null1.C
trunk/gcc/testsuite/g++.dg/warn/Wconversion-null.C
Removed:
trunk/gcc/testsuite/g++.old-deja/g++.other/null1.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c.opt
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/cp/cvt.c
trunk/gcc/doc/invoke.texi
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/warn/Wconversion2.C
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/testsuite/18_support/headers/cstddef/macros.cc
Propchange: trunk/gcc/testsuite/g++.dg/warn/Wconversion-null-2.C
('svn:mergeinfo' added)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35669
[Bug c++/35669] NULL (__null) not considered different from 0 with C++
--- Comment #27 from manu at gcc dot gnu dot org 2010-02-20 21:38 --- FIXED in GCC 4.5 -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35669
[Bug fortran/36932] unneeded temporary (2x)
--- Comment #13 from burnus at gcc dot gnu dot org 2010-02-20 21:46 --- Can this PR be closed? I think all items are fixed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36932
[Bug fortran/43072] unneeded temporary (s=s+f(a))
--- Comment #5 from burnus at gcc dot gnu dot org 2010-02-20 21:48 --- Can this PR be closed? I think it is fixed now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43072
[Bug fortran/41113] spurious _gfortran_internal_pack
--- Comment #22 from burnus at gcc dot gnu dot org 2010-02-20 21:51 --- Can this PR be closed as FIXED? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41113
[Bug fortran/41117] spurious _gfortran_internal_pack (II)
--- Comment #4 from burnus at gcc dot gnu dot org 2010-02-20 21:51 --- Can this PR be closed as FIXED? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41117
[Bug testsuite/31846] Logs are not being parsed correctly by testsuite and "test_summary" scripts.
--- Comment #4 from manu at gcc dot gnu dot org 2010-02-20 21:56 --- Rob, this is very old. Is it still a problem? -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31846
[Bug fortran/40973] Mark PRIVATE module functions as STATIC to faciliate optimization
--- Comment #2 from burnus at gcc dot gnu dot org 2010-02-20 22:08 --- Marking it as STATIC will become difficult with SUBMODULES as one has several .o files belonging to one common MODULE, i.e. the function shall be accessible by all submodules, which are scattered over several .o files. With -flto -fwhole-program it should be possible to optimize the function away even without using STATIC. (In reply to comment #1) > How about this (somewhat constructed) example: I fail to see why __m_MOD_two is needed - it is not called anywhere. > ! interface module, file (a) > MODULE M > PRIVATE :: two [...] > integer FUNCTION two() [...] > END MODULE > ! implementation, file (b) > SUBROUTINE one(a) > USE M > integer :: a > a = two() > END SUBROUTINE one You are calling "two_" which is a REAL function and you are not calling an INTEGER function and specifically you are not calling __m_MOD_two. "two" is just an implicitly type external function. > SUBROUTINE three(a) > integer :: a > a = two() > END SUBROUTINE three This one should be identical to "one". > I often use modules simply to provide interfaces for subroutines implemented > in other files and compiled into libraries You should use ABSTRACT INTERFACE to provide interfaces... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40973
[Bug target/43067] ICE: SIGSEGV with -fschedule-insns -mxop
--- Comment #2 from uros at gcc dot gnu dot org 2010-02-20 22:11 --- Subject: Bug 43067 Author: uros Date: Sat Feb 20 22:11:32 2010 New Revision: 156929 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156929 Log: PR target/43067 * config/i386/sse.md (xop_mulv2div2di3_low): Change type attribute to ssemul. (xop_mulv2div2di3_high): Ditto. testsuite/ChangeLog: PR target/43067 * gcc.target/i386/pr43067.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr43067.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/sse.md trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43067
[Bug libfortran/32972] performance of pack/unpack
--- Comment #25 from burnus at gcc dot gnu dot org 2010-02-20 22:11 --- Can you summarize what it left to do? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32972
[Bug fortran/31014] missed-optimization: unnecessary invokation of _gfortran_internal_pack
--- Comment #3 from burnus at gcc dot gnu dot org 2010-02-20 22:17 --- Close as FIXED. Seemingly, the issues reported here are now fixed. Cf. http://gcc.gnu.org/ml/fortran/2010-02/msg00162.html and PR 36932, PR 36933, PR 43072, and PR 43111. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31014
[Bug target/43067] ICE: SIGSEGV with -fschedule-insns -mxop
--- Comment #3 from ubizjak at gmail dot com 2010-02-20 22:19 --- Fixed. -- ubizjak at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2010- ||02/msg00831.html Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43067
[Bug middle-end/31980] ICE in cancel_option()
--- Comment #2 from manu at gcc dot gnu dot org 2010-02-20 23:02 --- Is this solved? Anyway, this does not seem to be a bug in GCC. -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31980
[Bug testsuite/32031] The 'status' of using the "LAST_UPDATED" file is unclear or inconsistent
--- Comment #3 from manu at gcc dot gnu dot org 2010-02-20 23:10 --- (In reply to comment #2) > Either a gcc-4_3-trunk/contrib/README (might as well describe all the files) > _or_ a oneliner in gcc-4_3-trunk/README that explains to: > > Use "contrib/gcc_update" to get the newest revision from SVN. If you write a contrib/README describing all files (there is a description within each file), I will be happy to commit it for you. Otherwise, this is not really a bug, so I am closing it. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32031
[Bug testsuite/32063] "contrib/test_summary" script could output results more neatly
--- Comment #6 from manu at gcc dot gnu dot org 2010-02-20 23:17 --- (In reply to comment #3) > > I'll be glad to make the patch, just send me the scripts that are used to read > the reports and perform "breakage e-mailing" and I'll ensure that my patch is > compatable. contrib/test_summary > We are all (some of us anyways) kinda working on the "Blocker" problem at the > moment. Those sorts of things come first. The report _might_ be dealt with in > the next 2-6 months -- depending on how people feel about the appearance of > those web pages. The problem is that we have too many important bugs and too many trivial ones. Few of us look at trivial stuff and we are really overwhelmed. And this one is beyond trivial. If you do not do it yourself, I assure you it will be there in 50 years. > Your electricity company thanks you for your support. (Mine is non-profit). Really? Where is that? That is awesome. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32063
[Bug testsuite/32063] "contrib/test_summary" script could output results more neatly
--- Comment #7 from manu at gcc dot gnu dot org 2010-02-20 23:18 --- Bah, Rob is not even reading mail anymore, so why bother to have this open. No patch, no clear problem, no one is interested, so closing. -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32063
[Bug other/32105] Compiler warning in gcc
--- Comment #4 from manu at gcc dot gnu dot org 2010-02-20 23:23 --- Is this a valid bug? Really, you should split the bug into components so the respective maintainers can know about their corresponding warnings. Not everybody reads all PRs. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32105
[Bug target/32180] Paranoia UCB GSL TestFloat libm tests fail - accuracy of recent gcc math poor
--- Comment #25 from manu at gcc dot gnu dot org 2010-02-20 23:43 --- I understand that this is INVALID because all the points raised by comment #21. If crlibm is better than what we have, but we cannot use it, it is the same as if it didn't exist. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32180
[Bug other/32185] unused result warnings and -werror
--- Comment #5 from manu at gcc dot gnu dot org 2010-02-20 23:47 --- Is this stil valid? Patches go to gcc-patches, see also http://gcc.gnu.org/contribute.html -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32185
[Bug c++/35669] NULL (__null) not considered different from 0 with C++
-- jason at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35669
[Bug c++/32205] "defined but not used" warning given or not depending on other errors
--- Comment #3 from manu at gcc dot gnu dot org 2010-02-20 23:56 --- (In reply to comment #1) > The main reason why is that we don't process the initializer for foo if we get > an error. What? Don't we process the initializer of foo before processing bar()? That is weird. But we still parse that foo is initialized, so there should be no warning. This is confirmed in trunk. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC host triplet|x86_64-unknown-linux-gnu| Known to fail||4.4.0 Last reconfirmed|-00-00 00:00:00 |2010-02-20 23:56:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32205
[Bug middle-end/32447] without-decimal-float needed
--- Comment #4 from manu at gcc dot gnu dot org 2010-02-21 00:02 --- This is not going to happen because no one working on GCC is interested on pursuing it. Your only chance is 1) to do it yourself to show GCC devs that can be done and it is beneficial. 2) to pay someone to do it Both of those options have the risk that GCC devs may not be convinced and decide to not apply your patch. Sorry, it is nothing personal, just explaining what the real situation is. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32447
[Bug c++/32291] -Wformat either too picky or not picky enough
--- Comment #2 from manu at gcc dot gnu dot org 2010-02-21 00:14 --- Apart from Andrea's answer, you can use PRIu32 to print uint32_type. See inttypes.h in your system for the complete list. Closing. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32291
[Bug c++/32525] Request for new warning: useless dynamic_casts
--- Comment #8 from manu at gcc dot gnu dot org 2010-02-21 00:17 --- (In reply to comment #5) > I filed the bug because it seems like this would be at least marginally > useful, > and this way people can find it / read the discussion / whatever. Even if the > end result is WONTFIX, that at least lets anyone in the future who searches > the > bug database know what the situation is. Fair enough. Thanks everybody for the comments. Closing then. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32525
[Bug c/32587] gcc fails to issue "warning: suggest parentheses around assignment used as truth value"
--- Comment #1 from manu at gcc dot gnu dot org 2010-02-21 00:21 --- Confirmed in GCC 4.5 This whole business with the parenthesis to avoid warning in this case always seemed fishy to me. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-02-21 00:21:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32587
[Bug c/25733] missed diagnostic about assignment used as truth value.
--- Comment #7 from manu at gcc dot gnu dot org 2010-02-21 00:30 --- (In reply to comment #3) > As another data-point, > > if ( (a=10) ) ; > > also doesn't warn. I'm not sure what the standard says on that, but other > contemporary compilers do give the an "assignment used as truth value" warning > for the example above. > How do other compilers deal with false positives? That is, how can a programmer specify that they really want to do an assignment? We could use a cast to bool. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25733
[Bug c++/32614] -fmessage-length documentation and implementation disagree
--- Comment #1 from manu at gcc dot gnu dot org 2010-02-21 00:31 --- *** Bug 32587 has been marked as a duplicate of this bug. *** -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||fritz at intrinsity dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32614
[Bug c/32587] gcc fails to issue "warning: suggest parentheses around assignment used as truth value"
--- Comment #2 from manu at gcc dot gnu dot org 2010-02-21 00:31 --- *** This bug has been marked as a duplicate of 32614 *** -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32587
[Bug c/32587] gcc fails to issue "warning: suggest parentheses around assignment used as truth value"
--- Comment #3 from manu at gcc dot gnu dot org 2010-02-21 00:32 --- wrong duplicate -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32587
[Bug c/32587] gcc fails to issue "warning: suggest parentheses around assignment used as truth value"
--- Comment #4 from manu at gcc dot gnu dot org 2010-02-21 00:33 --- *** This bug has been marked as a duplicate of 25733 *** -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32587
[Bug c/25733] missed diagnostic about assignment used as truth value.
--- Comment #8 from manu at gcc dot gnu dot org 2010-02-21 00:33 --- *** Bug 32587 has been marked as a duplicate of this bug. *** -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||fritz at intrinsity dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25733
[Bug c/25733] missed diagnostic about assignment used as truth value.
--- Comment #9 from manu at gcc dot gnu dot org 2010-02-21 00:34 ---
Another testcase:
int bar(int a, int b, int c)
{
if ((b = c) && (a == 0))
{
return 0;
}
return 1;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25733
[Bug c/29280] misleading warning for assignment used as truth construct
--- Comment #3 from manu at gcc dot gnu dot org 2010-02-21 00:38 --- I agree with the reporter. The warning text suggests what it is actually not the most common solution and it fails miserably in some cases (see PR 25733). -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||diagnostic Last reconfirmed|-00-00 00:00:00 |2010-02-21 00:38:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29280
[Bug c++/32614] -fmessage-length documentation and implementation disagree
--- Comment #2 from manu at gcc dot gnu dot org 2010-02-21 00:46 --- Tom, this is not a code bug. Perhaps is the wrong default. So please, unless you want to change the current default, commit your doc patch and let someone interested in changing the default to get a patch approved for that. -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-02-21 00:46:30 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32614
[Bug target/32750] Bogus warning "00000003fffffffc shortened to 00000000fffffffc"
--- Comment #3 from manu at gcc dot gnu dot org 2010-02-21 00:48 --- 4.1.x is already too old, so if you cannot reproduce it in a recent version, we consider this FIXED. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32750
[Bug target/32750] Bogus warning "00000003fffffffc shortened to 00000000fffffffc"
--- Comment #4 from manu at gcc dot gnu dot org 2010-02-21 00:48 --- Thanks for the report, nonetheless. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32750
[Bug target/32775] init_machine_status doc bug
--- Comment #1 from manu at gcc dot gnu dot org 2010-02-21 00:52 --- Confirmed. Please send a patch to gcc-patc...@gcc.gnu.org. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-02-21 00:52:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32775
[Bug libstdc++/33852] incorrect text formating in "std::cout" with UTF-8
--- Comment #4 from manu at gcc dot gnu dot org 2010-02-21 01:05 --- I understand that this is not a bug, so closing. Please Paolo, reopen if I am mistaken. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33852
[Bug c++/33801] Missing warning
--- Comment #1 from manu at gcc dot gnu dot org 2010-02-21 01:06 --- What does EDG say? What is the problem? This bug summary is too vague. -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33801
[Bug c/25733] missed diagnostic about assignment used as truth value.
--- Comment #10 from bangerth at gmail dot com 2010-02-21 01:25 --- (In reply to comment #7) > (In reply to comment #3) > > As another data-point, > > > > if ( (a=10) ) ; > > > > also doesn't warn. I'm not sure what the standard says on that, but other > > contemporary compilers do give the an "assignment used as truth value" > > warning > > for the example above. > > > > How do other compilers deal with false positives? That is, how can a > programmer > specify that they really want to do an assignment? > > We could use a cast to bool. I think at least in C++ the warning is useful. Conditions in if(...) statements have type bool, and things like if (a=10) use the implicit conversion from int to bool. If a programmer wants to avoid the warning, one can always be explicit and write if ( (a=10) != 0) W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25733
[Bug c++/31843] -Wformat-nonliteral differs between gcc and g++
--- Comment #2 from manu at gcc dot gnu dot org 2010-02-21 01:27 --- Confirmed. The problem is that constant_value_1 has the following code: if (!init || !TREE_TYPE (init) || (integral_p ? !INTEGRAL_OR_ENUMERATION_TYPE_P (TREE_TYPE (init)) : (!TREE_CONSTANT (init) /* Do not return an aggregate constant (of which string literals are a special case), as we do not want to make inadvertent copies of such entities, and we must be sure that their addresses are the same everywhere. */ => || TREE_CODE (init) == CONSTRUCTOR || TREE_CODE (init) == STRING_CST))) So it does not consider string constant as constant initializers. I think this is probably breaking more than this warning. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-02-21 01:27:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31843
[Bug c++/33801] Missing warning
--- Comment #2 from bangerth at gmail dot com 2010-02-21 01:27 --- I don't see what should be warned about. The 'const' in the signature of 'f' has no effect here, but it also doesn't hurt -- its presence or absence simply doesn't make a difference. W. -- bangerth at gmail dot com changed: What|Removed |Added CC||bangerth at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33801
[Bug libstdc++/33852] incorrect text formating in "std::cout" with UTF-8
--- Comment #5 from paolo dot carlini at oracle dot com 2010-02-21 01:31 --- Reopen... -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33852
[Bug libstdc++/33852] incorrect text formating in "std::cout" with UTF-8
--- Comment #6 from paolo dot carlini at oracle dot com 2010-02-21 01:31 --- *** This bug has been marked as a duplicate of 35353 *** -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33852
[Bug libstdc++/35353] C++ wide character locale doesn't work
--- Comment #14 from paolo dot carlini at oracle dot com 2010-02-21 01:31 --- *** Bug 33852 has been marked as a duplicate of this bug. *** -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||siegerstein at pochta dot ru http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35353
[Bug middle-end/36041] Speed up builtin_popcountll
--- Comment #7 from manu at gcc dot gnu dot org 2010-02-21 01:34 --- Given Richard's comment, I am confirming this. Joseph, bugzilla is too busy to keep track of conversations. If you have questions about gcc development, go to g...@gcc.gnu.org. See also http://gcc.gnu.org/contribute.html If you send a patch to gcc-patc...@gcc.gnu.org, you may get more specific feedback. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-02-21 01:34:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36041
[Bug c/25733] missed diagnostic about assignment used as truth value.
--- Comment #11 from manu at gcc dot gnu dot org 2010-02-21 01:43 --- I am not saying that the warning is not useful. I am saying that the current behaviour of not warning if there are parenthesis is not ideal. So either: if ((bool) a = 0) or if ( (a=0) != 0) seem much better choices for avoiding warning. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25733
[Bug fortran/43115] bug with gfortran on Windows vista, correct on Linux
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2010-02-21 04:06 --- I have been able to reproduce this with the binary from the wiki. We get an END condition at line 5 of the test file. You have to use the test case with: character(len = n2):: ligne I have a vague recollection of this bug being fixed since April 2009. Most likely PR41328. The length of the read falls between the CR and the LF. It is fixed on trunk, so we really need to get that binary on the wiki updated. Lets hold this PR open until that happens. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-02-21 04:06:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43115
[Bug libstdc++/22200] numeric_limits::is_modulo is inconsistent with gcc
--- Comment #30 from veksler at il dot ibm dot com 2010-02-21 07:52 --- (In reply to comment #25) > It would probably be useful to add a preprocessor macro when -fwrapv is > in effect. > Wouldn't it be a violation of the one definition rule (ODR), when one translation unit is compiled with -fwrapv and another without? In that case this would be a regression. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200
