Re: New option: -fstatic-libgfortran
Hi!
Sorry about the (possibly off) question: would this apply also to
GMP/MPFR, if not, wouldn't it make sense?
Philippe
François-Xavier Coudert wrote:
Hi all,
Attached is a first draft of a patch to add a -fstatic-libgfortran
option. This new option is recognized by the driver and instead of
adding -lgfortran to the various subprocesses, it adds -Wl,-Bstatic
-lgfortran -Wl,-Bdynamic. I have two questions about this:
+ linkers other than the GNU linker might have problems with that.
is there a more general way of doing this? or should it be conditional
on some macro, like HAVE_LD_STATIC_DYNAMIC?
+ when -static is used later in the command line, this trick doesn't
work; would %{!static:-Wl,-Bstatic} -lgfortran
%{!static:-Wl,-Bdynamic} be a good replacement?
Thanks for the help, I'm a bit a loss with non-GNU linkers... :(
FX
Name: static-libgfortran.diff
static-libgfortran.diffType: text/x-patch
Encoding: base64
Re: New option: -fstatic-libgfortran
Philippe Schaffnit wrote: Sorry about the (possibly off) question: would this apply also to GMP/MPFR, if not, wouldn't it make sense? It wouldn't make sense -- GMP and MPFR are never linked into the compiled output at all. (They're only used within the compiler itself, for processing constant values and suchlike, and then the results from that are put in the compiled file.) - Brooks
Re: New option: -fstatic-libgfortran
Oops! Thanks a lot for your reply. Philippe Brooks Moses wrote: Philippe Schaffnit wrote: Sorry about the (possibly off) question: would this apply also to GMP/MPFR, if not, wouldn't it make sense? It wouldn't make sense -- GMP and MPFR are never linked into the compiled output at all. (They're only used within the compiler itself, for processing constant values and suchlike, and then the results from that are put in the compiled file.) - Brooks
Re: New option: -fstatic-libgfortran
Sorry about the (possibly off) question: would this apply also to GMP/MPFR, if not, wouldn't it make sense? GMP and MPFR are host libraries, so it is actually an independent issue. However, it might be worth having --with-static-gmp and --with-static-mpfr to request static linking of these libraries into the compiler. I think I suggested the idea (maybe even a patch, but I can't find it in the mailing-list archives) when gmp/mpfr was still only used by Fortran. In the end, some people will think it's stretching the configury too much for a specific purpose, and some people will think it's just a good option to have. (I'm in the second group.) Let's wait and see what people think of the idea. FX
Bonsoir
Bonsoir monsieur, je viens par ce mail solliciter votre aide pour l'ex#233;cution d'une transaction financi#232;re. J'aimerais investir dans l'immobilier ou un domaine prosp#232;re dans votre pays que vous pourrez me conseiller. J'ai sept millions cinq cents mille dollars am#233;ricains ($7,500,000.00 US) que je voudrais investir et je vous donnerai g#233;n#233;reusement 15% de toute la somme en contre partie de votre aide en recevant les fonds sur votre compte dans votre pays.Veuillez s'il vous plait me contacter imm#233;diatement #224; mon adresse email ([EMAIL PROTECTED]) pour davantage d'explications. En attendant votre r#233;ponse imm#233;diate. Respectueusement. Mlle Simone ADOU
Re: GCC mini-summit - compiling for a particular architecture
On 4/23/07, Diego Novillo [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote on 04/23/07 14:40: Any references? Yes, at the last HiPEAC conference Grigori Fursin presented their interactive compilation interface, which could be used for this. http://gcc-ici.sourceforge.net/ That work is part of an European project called MilePost. We will present at the summit a part of this ongoing work, see the abstract: http://www.gccsummit.org/2007/view_abstract.php?content_key=37 Another related presentation at the summit is that of Haiping Wu: http://www.gccsummit.org/2007/view_abstract.php?content_key=9 Sebastian
Builtins-vs-libcalls-vs-optimised-away-vs-still-emitting-an-undefined-symbol-reference
Hi everyone,
Although I'm seeing this on 3.3.3, it appears to be determined by the
backend, so I think it's still reasonable to ask:
I have some code that calls __builtin_ffs, but entirely on compile-time
constants. When I compile it (using an inhouse custom ELF-target backend)
with -O2, it gets totally optimised away, but the compiler still emits an
undefined symbol reference to the library ffs() function:
-snip!-
/tmp $ ${libexecdir}/3.3.3/cc1.exe -O2 - -o -
int foo ()
{
return __builtin_ffs (32);
}
.file stdin
foo.global _ffs
.text
.align 2
.proc _foo
.global _foo
.type _foo, @function
_foo:
addir1,r0,0x6
jr r15
.endproc _foo
.size _foo, .-_foo
.ident GCC: (GNU) 3.3.3 (artimi-1.19)
-snip!-
When I retarget the same gcc at x86/cygwin, no such reference is emitted:
-snip!-
/tmp $ /repository/gcc-build/gcc-x86/gcc/cc1.exe-O2 - -o -
int foo ()
{
return __builtin_ffs (32);
}
.file stdin
foo.text
.p2align 4,,15
.globl _foo
.def_foo; .scl2; .type 32; .endef
_foo:
pushl %ebp
movl$6, %eax
movl%esp, %ebp
popl%ebp
ret
-snip!-
Does anyone know off the top of their head if this is simply a side-effect
of the fact that i386.md supplies an rtl insn for ffs, where my custom target
doesn't? Or is it perhaps an elf-vs-PE difference? I couldn't find anything
to explain this behaviour in the manual.
I can kind-of work around it by tricking the compiler into thinking
__builtin_ffs can be elided (as no body is ever required by a static
inline[*])
-snip!-
/tmp $ ./cc1.exe -O2 - -o -
static inline int __builtin_ffs (int);
int foo ()
{
return __builtin_ffs (32);
}
.file stdin
foo
.text
.align 2
.proc _foo
.global _foo
.type _foo, @function
_foo:
; 010
; frame size 0: local_vars_size 0 out_args_size 0 pretend_args_size 0
; mul_save_size 0 gpr_save_size 0 lr_save_ 0 iar_save_ 0 fp_save_ 0
addir1,r0,0x20
j ___builtin_ffs ; sibcall_value insn ;
.endproc _foo
.size _foo, .-_foo
?
stdin:1: warning: `__builtin_ffs' used but never defined
.ident GCC: (GNU) 3.3.3 (artimi-1.19)
-snip!-
but that leaves me with an ugly warning. Does anyone know a better way to
eliminate the undefined reference? (I'm currently just supplying a dummy
version of _ffs() in my source solely in order to satisfy the linker).
cheers,
DaveK
[*] - before the recent changes for C99 compatibility, of course!
--
Can't think of a witty .sigline today
Re: New option: -fstatic-libgfortran
On Tue, Apr 24, 2007 at 10:55:56AM +0200, François-Xavier Coudert wrote: Sorry about the (possibly off) question: would this apply also to GMP/MPFR, if not, wouldn't it make sense? GMP and MPFR are host libraries, so it is actually an independent issue. However, it might be worth having --with-static-gmp and --with-static-mpfr to request static linking of these libraries into the compiler. I think I suggested the idea (maybe even a patch, but I can't find it in the mailing-list archives) when gmp/mpfr was still only used by Fortran. In the end, some people will think it's stretching the configury too much for a specific purpose, and some people will think it's just a good option to have. (I'm in the second group.) Let's wait and see what people think of the idea. I just keep this local patch. H.J. --- gcc/Makefile.in.gmp 2006-05-19 06:23:09.0 -0700 +++ gcc/Makefile.in 2006-05-19 13:20:17.0 -0700 @@ -295,7 +295,7 @@ ZLIB = @zlibdir@ -lz ZLIBINC = @zlibinc@ # How to find GMP -GMPLIBS = @GMPLIBS@ +GMPLIBS = -Wl,-Bstatic @GMPLIBS@ -Wl,-Bdynamic GMPINC = @GMPINC@ CPPLIB = ../libcpp/libcpp.a
bitfield handling on m68k broken
Hi,
Something broke the bitfield handling recently and before I delve deeper
into it, I'm hoping someone admits guilt. :)
This is taken from execute/20040709-1.c:
struct K { unsigned int k : 6, l : 1, j : 10, i : 15; };
struct K retmeK (struct K x)
{
return x;
}
This produces the following code:
retmeK:
link.w %fp,#0
move.l %d3,-(%sp)
move.l %d2,-(%sp)
clr.l %d0
move.l 8(%fp),%d1
bfextu %d1{#7:#10},%d3
bfextu %d1{#17:#15},%d2
bfins %d2,%d0{#17:#15}
bfins %d3,%d0{#7:#10}
- moveq #26,%d2
lsr.l %d2,%d1
bfins %d1,%d0{#0:#7}
move.l (%sp)+,%d2
move.l (%sp)+,%d3
unlk %fp
rts
The problem here is that the shift is off by one. The copying of the k/l
field is already wrong when it gets to the RTL phase:
(insn 11 10 13 3 (set (subreg:SI (reg:QI 32 [ x$B0F7 ]) 0)
(zero_extract:SI (reg/v:SI 35 [ x ])
(const_int 7 [0x7])
(const_int 0 [0x0]))) -1 (nil)
(nil))
(insn 15 14 16 3 (set (subreg:SI (reg:QI 36) 0)
(zero_extract:SI (subreg:SI (reg:QI 32 [ x$B0F7 ]) 0)
(const_int 7 [0x7])
(const_int 24 [0x18]))) -1 (nil)
(nil))
(insn 16 15 17 3 (set (zero_extract:SI (reg:SI 33 [ D.1548 ])
(const_int 7 [0x7])
(const_int 0 [0x0]))
(subreg:SI (reg:QI 36) 0)) -1 (nil)
(nil))
The offset of 24 in insn 15 is wrong. I'm not that familiar with the tree
optimizers, so I'm hoping for some help.
Even without this bug gcc usage of bitfield instruction has become a
little insane lately, e.g. 2.95/3.4 produce this code:
retmeK:
link.w %a6,#0
move.l 8(%a6),%d0
unlk %a6
rts
How can I get this back? In general bitfield instructions are a bit more
expensive, they are ok for extracting integer values when needed, but for
simply copying values like this it's overkill, what makes this worse is
that the rtl optimizers can often do as much with this (and in combination
with subreg it's not getting better...)
I'd be willing to look into this, but I need a little help here.
Thanks.
bye, Roman
Re: bitfield handling on m68k broken
Hi, On Tue, 24 Apr 2007, I wrote: simply copying values like this it's overkill, what makes this worse is that the rtl optimizers can often do as much with this (and in combination ^ not with subreg it's not getting better...) This should make more sense... bye, Roman
Difference in DWARF Info generated by GCC 3.4.6 and GCC 4.1.1
Hi all,
I am working with GCC 4.1.1, I need some clarification for the DWARF
information generated by this sample Program,
#include stdio.h
int fun(const char*, ...);
/* Variadic function */
int fun(const char *raj,...)
{
return 9;
}
int main()
{
fun(Hello world,3,2);
return 0;
}
For the sample program given above, the assembly code generated is:
/*
SP - Stack Pointer
FP - Frame Pointer
RP - Return Address Regnum
*/
.LC0:
.string Hello world
_main:
stwd FP, -(SP)
stwd RP, -(SP)
move SP, FP End of Func Prologue
move .LC0, D0 // Location of Hello World
saved in D0 for variable 'raj'
move 3, D1
move 2, D2
jump _fun
move 0, D0
ldwd (SP)+, RP
ldwd (SP)+, FP
ret
_fun:
stwd D3, -(SP)
stwd D2, -(SP)
stwd D1, -(SP)
stwd D0, -(SP)// Location of .LC0 - Hello World
stwd FP, -(SP)
move SP, FP End of Func Prologue
move 9, D0
ldwd (SP)+, FP
add 16, SP
ret
The frame base pointer in the DIE entry for _fun is taken as stack
pointer. Looking at the generated assembly for _fun,
stwd D0, -(SP)// Location of .LC0 - Hello World - variable 'raj'
stwd FP, -(SP)
after storing .LC0 (D0) in stack, the SP is decremented and FP is
stored. So the base offset with respect to SP for the variable raj is
4. But when looked at the debug output, the offset is zero.
# Readelf O/P for 4.1.1 ##
1103: Abbrev Number: 6 (DW_TAG_subprogram)
DW_AT_sibling : 12e
DW_AT_external: 1
DW_AT_name: fun
DW_AT_decl_file : 10
DW_AT_decl_line : 7
DW_AT_prototyped : 1
DW_AT_type: 53
DW_AT_low_pc : 0
DW_AT_high_pc : 0x14
DW_AT_frame_base : 1 byte block: 5f (DW_OP_reg15) [Stack Pointer]
211e: Abbrev Number: 7 (DW_TAG_formal_parameter)
DW_AT_name: raj
DW_AT_decl_file : 10
DW_AT_decl_line : 6
DW_AT_type: b9
DW_AT_location: 2 byte block: 91 0 (DW_OP_fbreg: 0)
###
Can any one point out what is going wrong here? The above program is
working properly with GCC 3.4.6.
Regards,
Rohit
On 16 Apr 2007 10:04:25 -0700, Ian Lance Taylor [EMAIL PROTECTED] wrote:
Rohit Arul Raj [EMAIL PROTECTED] writes:
1. In DIE for fun, with 3.4.6, the frame base is taken in terms of
Frame Pointer (DW_OP_reg14), where is in 4.1.1, it is taken in terms
of Stack Pointer (DW_OP_reg15).
(For my backend, reg-no 14 is Frame Pointer and reg-no 15 is Stack Pointer)
Is this the expected behavior?
It's correct if it matches the generated code. It is possible that
gcc 4.1.1 was able to eliminate the frame pointer in a case where gcc
3.4.6 was not.
2. For the variable, const char *raj, the DIE for 3.4.6 has the
location mentioned as (fbreg + 4 [offset] ) whereas for 4.1.1,
location is mentioned as (fbreg + 0).
Any specific reason for this behavior in GCC 4.1.1
Again, it is presumably reflecting the generated code.
Ian
Re: bitfield handling on m68k broken
Roman Zippel [EMAIL PROTECTED] writes:
This is taken from execute/20040709-1.c:
struct K { unsigned int k : 6, l : 1, j : 10, i : 15; };
struct K retmeK (struct K x)
{
return x;
}
This produces the following code:
retmeK:
link.w %fp,#0
move.l %d3,-(%sp)
move.l %d2,-(%sp)
clr.l %d0
move.l 8(%fp),%d1
bfextu %d1{#7:#10},%d3
bfextu %d1{#17:#15},%d2
bfins %d2,%d0{#17:#15}
bfins %d3,%d0{#7:#10}
- moveq #26,%d2
lsr.l %d2,%d1
bfins %d1,%d0{#0:#7}
move.l (%sp)+,%d2
move.l (%sp)+,%d3
unlk %fp
rts
The code generated by 4.3.0 20070122 still looks correct.
Even without this bug gcc usage of bitfield instruction has become a
little insane lately, e.g. 2.95/3.4 produce this code:
retmeK:
link.w %a6,#0
move.l 8(%a6),%d0
unlk %a6
rts
FWIW, I get this very code with 4.3.0 20070122 when compiling without
optimisation.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
And now for something completely different.
Re: Builtins-vs-libcalls-vs-optimised-away-vs-still-emitting-an-undefined-symbol-reference
Dave Korn [EMAIL PROTECTED] writes:
Although I'm seeing this on 3.3.3, it appears to be determined by the
backend, so I think it's still reasonable to ask:
I have some code that calls __builtin_ffs, but entirely on compile-time
constants. When I compile it (using an inhouse custom ELF-target backend)
with -O2, it gets totally optimised away, but the compiler still emits an
undefined symbol reference to the library ffs() function:
-snip!-
/tmp $ ${libexecdir}/3.3.3/cc1.exe -O2 - -o -
int foo ()
{
return __builtin_ffs (32);
}
.file stdin
foo.global _ffs
Is this really a reference? It just looks like a declaration. A
typical ELF assembler will not generate an undefined symbol merely
because it sees a .global pseudo-op.
It looks like this comes from an inappropriate call to
assemble_external. You should find out what is calling that for _ffs.
Ian
Re: What's the status of autovectorization for MMX and 3DNow!?
Uros Bizjak [EMAIL PROTECTED] дÈëÏûÏ¢ÐÂÎÅ:[EMAIL PROTECTED] Hello! I'm particularly interested in this patch (http://gcc.gnu.org/ml/gcc-patches/2005-07/msg01128.html); pretty nice for users of Pentium 3 and Athlon. Has it been or will it be integrated into mainline? This patch heavily depends on the functionality of optimize mode switching pass. Unfortunatelly, there is currently no way to tell optimize_mode_switching() which modes are exclusive. Due to the way how the emms switching patch was designed, it expects that either MMX or X87 mode can be active at once, to properly switch between x87 and MMX registers. PR target/19161 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19161) comment #17 has an example of the control flow that can block both register sets at once. Otherwise, the patch works as expected. Sorry to dig this old thing old, but will u continue to work on this once the problem you mentioned above gets resolved? And what about 3DNow! support? Just curious:-) -- Zuxy
Re: Where is gstdint.h
[EMAIL PROTECTED] wrote: Tim Prince wrote: [EMAIL PROTECTED] wrote: Where is gstdint.h ? Does it acctually exist ? libdecnumber seems to use it. decimal32|64|128.h's include decNumber.h which includes deccontext.h which includes gstdint.h When you configure libdecnumber (e.g. by running top-level gcc configure), gstdint.h should be created, by modifying stdint.h. Since you said nothing about the conditions where you had a problem, you can't expect anyone to fix it for you. If you do want it fixed, you should at least file a complete PR. As it is more likely to happen with a poorly supported target, you may have to look into it in more detail than that. When this happened to me, I simply made a copy of stdint.h to get over the hump. This might happen when you run the top level gcc configure in its own directory. You may want to try to make a new directory elsewhere and run configure there. pwd .../my-gcc-source-tree mkdir ../build cd ../build ../my-gcc-source-tree/configure make If you're suggesting trying to build in the top level directory to see if the same problem occurs, I would expect other problems to arise. If it would help diagnose the problem, and the problem persists for a few weeks, I'd be willing to try it. Tim you cleared this one up earlier, the gstdint.h was in the build tree after all. Aaron
RE: Builtins-vs-libcalls-vs-optimised-away-vs-still-emitting-an-undefined-symbol-reference
On 24 April 2007 15:34, Ian Lance Taylor wrote:
Dave Korn writes:
Although I'm seeing this on 3.3.3, it appears to be determined by the
backend, so I think it's still reasonable to ask:
I have some code that calls __builtin_ffs, but entirely on compile-time
constants. When I compile it (using an inhouse custom ELF-target backend)
with -O2, it gets totally optimised away, but the compiler still emits an
undefined symbol reference to the library ffs() function:
-snip!-
/tmp $ ${libexecdir}/3.3.3/cc1.exe -O2 - -o -
int foo ()
{
return __builtin_ffs (32);
}
.file stdin
foo.global _ffs
Is this really a reference? It just looks like a declaration. A
typical ELF assembler will not generate an undefined symbol merely
because it sees a .global pseudo-op.
It could well be an assembler issue then, but yes, it certainly ends up as a
type 'U' symbol in the output object. (I was fooled by that seeming label
'foo' at the start of the .global line; in fact, that's an artefact of
outputting to the console, it comes from stderr not stdout.)
It looks like this comes from an inappropriate call to
assemble_external. You should find out what is calling that for _ffs.
Thanks, I will take a look.
cheers,
DaveK
--
Can't think of a witty .sigline today
Re: Builtins-vs-libcalls-vs-optimised-away-vs-still-emitting-an-undefined-symbol-reference
.file stdin foo.global _ffs Is this really a reference? It just looks like a declaration. A typical ELF assembler will not generate an undefined symbol merely because it sees a .global pseudo-op. I think gas 2.17 counts as a typical ELF assembler. It does create undefined symbols in response to a .global pseudo-op. There was a patch to the c++ frontend recently to avoid a similar problem with EH personality routines. Paul
RE: Builtins-vs-libcalls-vs-optimised-away-vs-still-emitting-an-undefined-symbol-reference
On 24 April 2007 15:50, Dave Korn wrote:
On 24 April 2007 15:34, Ian Lance Taylor wrote:
It looks like this comes from an inappropriate call to
assemble_external. You should find out what is calling that for _ffs.
Heh, surely you mean You should find out what is calling that, ffs! ;-)
Thanks, I will take a look.
Didn't take long, and seems to show immediately what the problem is:
Continuing.
Breakpoint 2, assemble_external (decl=0x7ff08a40) at
/tools/external_source/gnu/gcc-3.3.3/gcc/varasm.c:1712
(gdb) bt
#0 assemble_external (decl=0x7ff08a40) at
/tools/external_source/gnu/gcc-3.3.3/gcc/varasm.c:1712
#1 0x00417828 in build_external_ref (id=0x7ff32800, fun=1) at
/tools/external_source/gnu/gcc-3.3.3/gcc/c-typeck.c:1453
#2 0x00405f24 in yyparse () at c-parse.y:615
#3 0x0040b699 in c_common_parse_file (set_yydebug=0) at
/tools/external_source/gnu/gcc-3.3.3/gcc/c-lex.c:159
#4 0x00449808 in toplev_main (argc=5, argv=0xd38ca8) at
/tools/external_source/gnu/gcc-3.3.3/gcc/toplev.c:2142
#5 0x0044437a in main (argc=5, argv=0xd38ca8) at
/tools/external_source/gnu/gcc-3.3.3/gcc/main.c:35
(gdb) call debug_tree (decl)
function_decl 0x7ff08a40 __builtin_ffs
type function_type 0x7ff06510
type integer_type 0x7ff003f0 int SI
size integer_cst 0x7fee0288 constant 32
unit size integer_cst 0x7fee0330 constant 4
align 32 symtab 0 alias set -1 precision 32 min integer_cst
0x7fee0300 -2147483648 max integer_cst 0x7fee0318 2147483647
pointer_to_this pointer_type 0x7ff057f0
DI
size integer_cst 0x7fee06a8 constant 64
unit size integer_cst 0x7fee0900 constant 8
align 32 symtab 0 alias set -1
arg-types tree_list 0x7fee1f08 value integer_type 0x7ff003f0 int
chain tree_list 0x7fee1c80 value void_type 0x7ff017a0 void
readonly nothrow public external built-in SI file built-in line 0
built-in BUILT_IN_NORMAL:BUILT_IN_FFS attributes tree_list 0x7fee30c0
(mem:SI (symbol_ref:SI (ffs)) [0 S4 A32]) chain function_decl
0x7ff089d0
bcmp
Looking at the comments:
1700/* Output something to declare an external symbol to the
assembler.
1701 (Most assemblers don't need this, so we normally output
nothing.)
1702 Do nothing if DECL is not external. */
1703
1704void
1705assemble_external (decl)
1706 tree decl ATTRIBUTE_UNUSED;
- 1707{
1708 /* Because most platforms do not define ASM_OUTPUT_EXTERNAL,
the
1709 main body of this code is only rarely exercised. To
provide some
1710 testing, on all platforms, we make sure that the
ASM_OUT_FILE is
1711 open. If it's not, we should not be calling this
function. */
and the internals manual:
`ASM_OUTPUT_EXTERNAL (STREAM, DECL, NAME)'
A C statement (sans semicolon) to output to the stdio stream
STREAM any text necessary for declaring the name of an external
symbol named NAME which is referenced in this compilation but not
defined. The value of DECL is the tree node for the declaration.
This macro need not be defined if it does not need to output
anything. The GNU assembler and most Unix assemblers don't
require anything.
I'd say that I've inherited a thinko-fied version of ASM_OUTPUT_EXTERNAL that
is emitting a .global directive when it should be emitting a .extern (or, as
the Fine Manual says, just not bothering at all since I'm using GAS). Thanks
for the well-tuned hint!
cheers,
DaveK
--
Can't think of a witty .sigline today
Re: bitfield handling on m68k broken
Hi,
On Tue, 24 Apr 2007, Andreas Schwab wrote:
Even without this bug gcc usage of bitfield instruction has become a
little insane lately, e.g. 2.95/3.4 produce this code:
retmeK:
link.w %a6,#0
move.l 8(%a6),%d0
unlk %a6
rts
FWIW, I get this very code with 4.3.0 20070122 when compiling without
optimisation.
-fno-tree-sra does the same. I don't know if disabling this is the best
way to go as in some cases it makes sense, the problem is that there is
nothing that undoes this pass later, when needed.
This pass makes more sense with larger structures in memory, but with
small structures in registers it makes things worse, e.g. some C++
structure may look like this:
struct B { bool a, b, c, d; };
and this also produces lots of bitfield instructions...
bye, Roman
RE: Builtins-vs-libcalls-vs-optimised-away-vs-still-emitting-an-undefined-symbol-reference
On 24 April 2007 15:52, Paul Brook wrote: .file stdin foo.global _ffs Is this really a reference? It just looks like a declaration. A typical ELF assembler will not generate an undefined symbol merely because it sees a .global pseudo-op. I think gas 2.17 counts as a typical ELF assembler. It does create undefined symbols in response to a .global pseudo-op. I think that's what it's supposed to do - .global is for exporting a symbol that you intend to define. In my case, the backend is misusing it where it means .extern; this doesn't usually cause code breakage, because .global has all the effects of .extern, but it also emits the symbol - whether or not the symbol is later defined by a label in the assembler source. There was a patch to the c++ frontend recently to avoid a similar problem with EH personality routines. Couldn't see what you're referring to in cp/ChangeLog straight away, have you got a pointer/rough date/search term I can use? cheers, DaveK -- Can't think of a witty .sigline today
Re: Builtins-vs-libcalls-vs-optimised-away-vs-still-emitting-an-undefined-symbol-reference
Paul Brook [EMAIL PROTECTED] writes: .file stdin foo.global _ffs Is this really a reference? It just looks like a declaration. A typical ELF assembler will not generate an undefined symbol merely because it sees a .global pseudo-op. I think gas 2.17 counts as a typical ELF assembler. It does create undefined symbols in response to a .global pseudo-op. Whoops, you're right. I tested that, but I goofed the test. Ian
Re: What is the right usage of SAVE_EXPR?
On Apr 24, 2007, at 8:30 AM, Wolfgang Gellerich wrote: What is the policy concerning the usage of SAVE_EXPRs? Roughly, if you do something like: tree foo(a, b) return build (a, b); You don't need any saving. If you do: tree foo(a, b) return build (a, build (a, b)); You need to code this as: tree foo(a, b) a = save_expr (a); return build (a, build (a, b)); The person that does the building, does the saving, as they know they are going to reuse a value and duplicate evaluations would be wrong. I thought the respective language front end were responsible to enclose any expressions with side effects this way No. The first example above needs no saving. Only when a value is used more than once, does it need to be saved. However, also some of the code translating tree nodes into rtxes like some functions found in builtins.c worry about the re-evaluation of arguments and insert plenty of SAVE_EXPRs. Why is that necessary? Because they do as in the second example above.
Re: Does vectorizer support extension?
H. J. Lu [EMAIL PROTECTED] wrote on 24/04/2007 01:03:25: ... There are [EMAIL PROTECTED] vect]$ cat pmovzxbw.c typedef unsigned char vec_t; typedef unsigned short vecx_t; in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31667 By the way, this PR says Integer externsions aren't vectorized - but I think the testcase you are referring to does get vectorized, only not as efficiently as you would want it to (right?). * Also I wonder how the gcc code looks like when complete unrolling is applied (did you use -funoll-loops?). (like the point above, this is just so that we aompre apples w apples). It is similar. I am enclosing it at the end. thanks * I don't entirely follow the code that gcc generates what's that for exactly?: pxor%xmm2, %xmm2 movdqa %xmm2, %xmm1 pcmpgtb %xmm0, %xmm1 Is this part of the vec_unpack_hi, and if so - I wonder if there's a better way to model the vec_unpack_hi using the new sse4 instructions? That is for signed extension. I tried to model vec_unpack_hi with SSE4. It isn't easy to move N/2 high elemenets to N/2 low elemenets. just curious - why is it difficult? (couldn't you use a psrldq? is it too expensive?) dorit The best way to do it is to combine movdqa x(%rip), %xmm9 pmovsxbw %xmm9, %xmm11 into pmovsxbw x(%rip),%xmm11 and repeat it for N/2 elements. Of cause, we should only do it if vec_unpack_lo is a single instructions. However, I think we need a more general approach based on the number of elements in the resulting vector to handle, vec_extend, like, V4QI - V4SI V2QI - V2DI V2HI - V2DI They should be independent of vec_unpack. H.J. .file pmovsxbw.c .text .p2align 4,,15 .globl foo .type foo, @function foo: pxor %xmm2, %xmm2 movdqa x(%rip), %xmm9 movdqa x+16(%rip), %xmm6 movdqa %xmm2, %xmm10 movdqa %xmm2, %xmm7 movdqa x+32(%rip), %xmm3 movdqa %xmm2, %xmm4 pmovsxbw %xmm9, %xmm11 movdqa x+48(%rip), %xmm0 pcmpgtb %xmm9, %xmm10 pcmpgtb %xmm6, %xmm7 pmovsxbw %xmm6, %xmm8 pcmpgtb %xmm3, %xmm4 pmovsxbw %xmm3, %xmm5 pcmpgtb %xmm0, %xmm2 pmovsxbw %xmm0, %xmm1 punpckhbw %xmm10, %xmm9 punpckhbw %xmm7, %xmm6 punpckhbw %xmm4, %xmm3 punpckhbw %xmm2, %xmm0 movdqa %xmm11, y(%rip) movdqa %xmm9, y+16(%rip) movdqa %xmm8, y+32(%rip) movdqa %xmm6, y+48(%rip) movdqa %xmm5, y+64(%rip) movdqa %xmm3, y+80(%rip) movdqa %xmm1, y+96(%rip) movdqa %xmm0, y+112(%rip) ret .size foo, .-foo .ident GCC: (GNU) 4.3.0 20070423 (experimental) [trunk revision 124056] .section .note.GNU-stack,,@progbits
Re: Does vectorizer support extension?
On Tue, Apr 24, 2007 at 08:55:24PM +0300, Dorit Nuzman wrote: H. J. Lu [EMAIL PROTECTED] wrote on 24/04/2007 01:03:25: ... There are [EMAIL PROTECTED] vect]$ cat pmovzxbw.c typedef unsigned char vec_t; typedef unsigned short vecx_t; in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31667 By the way, this PR says Integer externsions aren't vectorized - but I think the testcase you are referring to does get vectorized, only not as efficiently as you would want it to (right?). I was referring to extensions including things like V2QI - V2DI. It isn't easy to move N/2 high elemenets to N/2 low elemenets. just curious - why is it difficult? (couldn't you use a psrldq? is it too expensive?) It needs more instructions. H.J.
[Announce] C++0x branch in GCC Subversion repository
Hello, I have just created a new branch for development of C++0x-specific features in the GNU C++ front end. The branch is branches/cxx0x-branch in Subversion, and information about this branch is available at http://gcc.gnu.org/projects/cxx0x.html. The intent of this branch is to collect all of the C++0x features into a single place, so that users of this branch can get a better feel for the C++0x language and we can work on handling interactions among C++0x features. Most implementations of C++0x features should still go into mainline, when possible, but on the branch we have a little more freedom to commit partially-implemented features. Jason Merrill and I will maintain this branch. As features on this branch mature, we hope to merge them into the mainline compiler under the experimental C++0x mode. Cheers, Doug
Changes to PR prioritization policy
I'd going to make a change to the policy for setting priorities for PRs in Bugzilla, to try to help address two issues that have been raised: 1. There may be vitally important bugs that are not regressions, and therefore do not get visibility before releases. (We have, in past, allowed changes on release branches for things like building the Linux kernel, even though they were not regressions.) 2. There may be regressions that appear more important to me than they really are. (In particular, people have mentioned optimization regressions: some of these may be unaavoidable consequences of improvements.) There's also a meta-issue: I don't want to be a bottleneck, for this or other aspects of GCC development. So, I'm going to make a few adjustments to the prioritization policy, effective immediately: 1. If you think that a PR deserves P1/P2 status (but doesn't have it) and you are a maintainer of the affected part of the compiler, please mark the issue as P3, add a note to the issue explaining why you think it should have higher priority, and CC: me. My default reaction will probably be to deprioritize the issue -- especially if there's no patch -- so make a good case. 2. If you think that a P2 PR should be taken off the radar, and you are a maintainer of the affected part of the compiler, you may downgrade it to P4 at will. 3. If you think that a P1 PR should be downgraded, and you are a maintainer of the affected part of the compiler, please add a note to the issue explaining why, and CC: me. The reason for the maintainer of the affected part of the compiler language above is that I will not be able to handle a stream of such requests coming from all over the place. I also want to give authority and responsibility to the various maintainers. So, if you're not a maintainer, but you want to make one of the changes above, lobby a maintainer. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
GCC 4.2.0 Status Report (2007-04-24)
[I apologize to those of you receiving duplicate copies of this mail. I thought so hard about copying people that I forgot to address to the list.] Table of contents: 1. PRs 2. Schedule 3. Rationale If you're in the CC: list, there are possible action items for you below. (Recent feedback was to provide more frequent status reports and to nag more -- I'll do my best!) PRs === At this point, we're very, very close to meeting the (admittedly limited) goal for 4.2.0 of having no P1 regressions from 4.1.x. The remaining PRs are: 1. PR 26792: libstdc++ on Darwin uses functions not present in the system libgcc This PR has apparently been fixed on the mainline. If a Darwin maintainer (Dale, Mike, Geoff) would like to backport this to 4.2, that would be great. 2. PR 30222: crash on gcc.target/i386/vectorize1.c This PR is apparently due to only part of a mainline patch being applied to 4.2. It was so diagnosed in December 2006, but nobody has identified the missing part of the mainline patch. Andrew, as you've diagnosed the problem, would you please identify the solution? 3. PR 30567: Wrong code with -O3 due to aliasing problems Richard G. has analyzed this and proposed a patch. Richard, is this ready to go? If not, do you need help? 4. PR 31360: Missed optimization I don't generally mark missed optimization bugs as P1, but not hoisting loads of zero out of a 4-instruction loop is bad. Zdenek has fixed this on mainline. Andrew says that patch has a bug. So, what's the story here? Schedule I'm not going to consider any of these issues blockers after Sunday, April 29. At that point, I plan to freeze the branch and build a release candidate. Then, about a week later, I plan to release 4.2.0. There has been more than enough time for people to test and fix bugs. Rationale = There are far too many constraints on releases to make everyone happy. All of the following objectives and suggestions have been made by intelligent, knowledgeable people: 1. Release early and often. 2. Take longer between releases so there's more time for major development. 3. Align releases with distributor schedules. 4. Take a feature-driven view: release when a pre-defined set of new features are available. 5. Take a time-driven view: release on a particular date, no matter what. 6. Take a quality-driven view: release when there are no severe bugs. I've gotten a little paralyzed with this release. I've wanted to take some combination of (4), (5), and (6), and I've made a hash of it. I'm going to cut my losses and 4.2.0 out the door. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
RE: Builtins-vs-libcalls-vs-optimised-away-vs-still-emitting-an-undefined-symbol-reference
On 24 April 2007 16:00, Dave Korn wrote: I'd say that I've inherited a thinko-fied version of ASM_OUTPUT_EXTERNAL Wrong, wrong, wrong. I don't have an ASM_OUTPUT_EXTERNAL at all. What I do have, however, is TARGET_ASM_GLOBALIZE_LABEL, which appears to somehow be equated with ASM_OUTPUT_EXTERNAL_LIBCALL. (gdb) bt #0 rtmi_globalize_label (stream=0x611010e8, name=0xd3a988 ffs) at /tools/external_source/gnu/gcc-3.3.3/gcc/config/rtmi/rtmi.c:158 #1 0x0047c05d in assemble_external_libcall (fun=0x7feb1b80) at /tools/external_source/gnu/gcc-3.3.3/gcc/varasm.c:1742 #2 0x004f37aa in emit_library_call_value_1 (retval=1, orgfun=0x7feb1b80, value=0x0, fn_type=LCT_CONST, outmode=SImode, nargs=1, p=0x23c37c ) at /tools/external_source/gnu/gcc-3.3.3/gcc/calls.c:3820 ...where it says: 3818 /* If this machine requires an external definition for library 3819 functions, write one out. */ - 3820 assemble_external_libcall (fun); Ah, it's elfos.h that does it: /* The standard SVR4 assembler seems to require that certain builtin library routines (e.g. .udiv) be explicitly declared as .globl in each assembly file where they are referenced. */ #define ASM_OUTPUT_EXTERNAL_LIBCALL(FILE, FUN) \ (*targetm.asm_out.globalize_label) (FILE, XSTR (FUN, 0)) That comment doesn't apply to me, so I can undef and redefine it in my tm.h to point to something that emits an .extern instead of a .global. As I see a lot of other ports do. Thanks for the help. cheers, DaveK -- Can't think of a witty .sigline today
[Committed] Fix PR30222 for 4.2 [Was: Re: GCC 4.2.0 Status Report (2007-04-24)]
On 4/24/07, Mark Mitchell [EMAIL PROTECTED] wrote:
2. PR 30222: crash on gcc.target/i386/vectorize1.c
This PR is apparently due to only part of a mainline patch being applied
to 4.2. It was so diagnosed in December 2006, but nobody has identified
the missing part of the mainline patch. Andrew, as you've diagnosed the
problem, would you please identify the solution?
This is what I am checking in to the 4.2 branch. I bootstrapped and
tested on x86-linux-gnu with no regressions and fixes the testcase.
This is a back port of part of:
http://gcc.gnu.org/ml/gcc-patches/2006-11/msg00702.html
Which was also part of the orginal patch which was supposed to fix this patch:
http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00566.html.
Thanks,
Andrew Pinski
2007-04-24 Andrew Pinski [EMAIL PROTECTED]
Roger Sayle [EMAIL PROTECTED]
PR middle-end/30222
* expmed.c (make_tree): Use the correct type, i.e. the inner
type, when constructing the individual elements of a CONST_VECTOR.
Index: ChangeLog
===
--- ChangeLog (revision 124139)
+++ ChangeLog (working copy)
@@ -1,3 +1,10 @@
+2007-04-24 Andrew Pinski [EMAIL PROTECTED]
+Roger Sayle [EMAIL PROTECTED]
+
+ PR middle-end/30222
+ * expmed.c (make_tree): Use the correct type, i.e. the inner
+ type, when constructing the individual elements of a CONST_VECTOR.
+
2007-04-24 Ian Lance Taylor [EMAIL PROTECTED]
PR tree-optimization/31605
Index: expmed.c
===
--- expmed.c(revision 124139)
+++ expmed.c(working copy)
@@ -4976,17 +4976,17 @@ make_tree (tree type, rtx x)
case CONST_VECTOR:
{
- int i, units;
- rtx elt;
+ int units = CONST_VECTOR_NUNITS (x);
+ tree itype = TREE_TYPE (type);
tree t = NULL_TREE;
+ int i;
- units = CONST_VECTOR_NUNITS (x);
/* Build a tree with vector elements. */
for (i = units - 1; i = 0; --i)
{
- elt = CONST_VECTOR_ELT (x, i);
- t = tree_cons (NULL_TREE, make_tree (type, elt), t);
+ rtx elt = CONST_VECTOR_ELT (x, i);
+ t = tree_cons (NULL_TREE, make_tree (itype, elt), t);
}
return build_vector (type, t);
[Bug tree-optimization/31611] [4.3 regression] ICE with -ftree-loop-linear in remove_referenced_var for loc == *0
--- Comment #3 from aldot at gcc dot gnu dot org 2007-04-24 08:52 --- Works with gcc version 4.2.0 20060922 -- aldot at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.3.0 Summary|ICE in remove_referenced_var|[4.3 regression] ICE with - |for loc == *0 |ftree-loop-linear in ||remove_referenced_var for ||loc == *0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31611
[Bug c/31679] New: Incorrect result of multiplication long long by 0xFFFFFFFFLL constant.
The following code when compiled with GCC 4.1.2 gives wrong result
res = . Code compiled with GCC 4.0.4 or GCC 3.3.3 gives right
result: res = .
In all these cases command line was: gcc test.c -o test.exe.
Adding optimization options for GCC 4.1.2 do change the output in this example,
but doesn't change anything in real program from which this code was extracted.
Code:
int main()
{
long long qhat = 1;
long long res = qhat * 0xLL;
printf(res = %llx\n, res);
}
gcc -v output:
Using built-in specs.
Target: i686-pc-cygwin
Configured with: ../gcc-4.1.2/configure --enable-languages=c
--prefix=/usr/local2 : (reconfigured) ../gcc-4.1.2/configur
e --enable-languages=c --prefix=/usr/local2 --enable-libmudflap :
(reconfigured) ../gcc-4.1.2/configure --enable-languag
es=c --prefix=/usr/local2 --enable-libmudflap : (reconfigured)
../gcc-4.1.2/configure --enable-languages=c --prefix=/usr
/local --enable-libmudflap
Thread model: single
gcc version 4.1.2
/usr/local/libexec/gcc/i686-pc-cygwin/4.1.2/cc1.exe -E -quiet -v
-D__CYGWIN32__ -D__CYGWIN__ -Dunix -D__unix__ -D__unix
-idirafter /usr/lib/../include/w32api -idirafter
/usr/local/lib/gcc/i686-pc-cygwin/4.1.2/../../../../../include/w32api
test.c -mtune=pentiumpro -fpch-preprocess -o test.i
ignoring nonexistent directory
/usr/local/lib/gcc/i686-pc-cygwin/4.1.2/../../../../i686-pc-cygwin/include
ignoring duplicate directory
/usr/local/lib/gcc/i686-pc-cygwin/4.1.2/../../../../../include/w32api
#include ... search starts here:
#include ... search starts here:
/usr/local/include
/usr/local/lib/gcc/i686-pc-cygwin/4.1.2/include
/usr/include
/usr/lib/../include/w32api
End of search list.
/usr/local/libexec/gcc/i686-pc-cygwin/4.1.2/cc1.exe -fpreprocessed test.i
-quiet -dumpbase test.c -mtune=pentiumpro -au
xbase test -version -o test.s
GNU C version 4.1.2 (i686-pc-cygwin)
compiled by GNU C version 3.3.3 (cygwin special).
GGC heuristics: --param ggc-min-expand=99 --param ggc-min-heapsize=130970
Compiler executable checksum: 4151625f98c48f709a3ef2b42ca0c20b
test.c: In function 'main':
test.c:5: warning: incompatible implicit declaration of built-in function
'printf'
as -o test.o test.s
/usr/local/libexec/gcc/i686-pc-cygwin/4.1.2/collect2.exe -Bdynamic
--dll-search-prefix=cyg -o test.exe /lib/crt0.o -L/u
sr/local/lib/gcc/i686-pc-cygwin/4.1.2
-L/usr/local/lib/gcc/i686-pc-cygwin/4.1.2/../../.. test.o -lgcc -lcygwin
-luser32
-lkernel32 -ladvapi32 -lshell32 -lgcc
--
Summary: Incorrect result of multiplication long long by
0xLL constant.
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vlasenko at bifit dot com dot ua
GCC build triplet: i686-pc-cygwin
GCC host triplet: i686-pc-cygwin
GCC target triplet: i686-pc-cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31679
[Bug libfortran/27740] libgfortran should use versioned symbols
--- Comment #15 from jb at gcc dot gnu dot org 2007-04-24 10:09 --- Subject: Bug 27740 Author: jb Date: Tue Apr 24 10:08:52 2007 New Revision: 124098 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124098 Log: 2007-04-24 Janne Blomqvist [EMAIL PROTECTED] PR fortran/27740 * configure.ac: New test to determine if symbol versioning is supported. * Makefile.am: Use result of above test to add appropriate linker flags. * gfortran.map: New file. * configure: Regenerated. * Makefile.in: Regenerated. * config.h.in: Regenerated. Added: trunk/libgfortran/gfortran.map Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/Makefile.am trunk/libgfortran/Makefile.in trunk/libgfortran/config.h.in trunk/libgfortran/configure trunk/libgfortran/configure.ac -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27740
[Bug libfortran/27740] libgfortran should use versioned symbols
--- Comment #16 from fxcoudert at gcc dot gnu dot org 2007-04-24 10:35 --- Fixed on mainline. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27740
[Bug libstdc++/25191] exception_defines.h #defines try/catch
--- Comment #34 from l dot lunak at suse dot cz 2007-04-24 10:54 --- I think the reason why the discussion here is so complicated is that you libstdc++ people are, because of exception_defines.h, confused about what -fno-exceptions actually does. From comment #15: Then, why what is this PR is about in the first place? -fno-exceptions turns try/catch into macros with specified semantics. That's clearly not true. It is libstdc++ that changes the try/catch keywords into macros and _changes_ their semantics. Also, again from comment #15: It is also a simple fact that GCC documents what happens with -fno-exceptions. - Sorry, but where? The info/man pages only say You may also wish to disable this option if you are compiling older C++ programs that don't use exception handling., but it doesn't say anything more about -fno-exceptions. What -fno-exceptions does (when libstdc++ is not used) is that it disables exceptions support. If any code requiring exceptions support is actually used, an error is generated (try compiling the testcase from comment #4 with -fno-exceptions and without the string include). This is the same like when asking for full ANSI compliance when compiling and using GNU extensions in the code. What libstdc++ does is that it (silently, to make it even worse) globally changes the semantics of the try/catch keywords, preventing the compiler from producing the error message and changing the behaviour of the compiled code, which may lead to incorrect results. Comment #2 also doesn't hold much of value, since if libstdc++ tries to be as much conforming as possible, why does it change semantics of C++ keywords? Also, if you argue against __try/__catch, why do you already use __throw_exception_again, which is just a different name for throw? If you can use this, you can as well use __try and __catch. Since try/catch can be redefined, try and catch used in the libstdc++ code clearly are not the actual normal C++ keywords. Please do as the original comment says and use __try/__catch instead of changing semantics of C++ keywords. What libstdc++ now does is very clearly a bug. The severity of this bug should be also raised since this bug can silently change code behaviour of any code using libstdc++. -- l dot lunak at suse dot cz changed: What|Removed |Added CC||l dot lunak at suse dot cz http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
[Bug c/31680] New: Cannot create DLL with exported stdcall functions because compiler exports the functions without the @N decoration
Take the following C test code. I want to make a DLL which exports stdcall
HelloWorld function.
test.c:
__attribute__((dllexport)) void __attribute__((__stdcall__)) HelloWorld()
{
}
Compiling linking it gives the following error during linking with GCC 4.3.0,
while it works fine with GCC 3.4.5.
$ i586-mingw32msvc-gcc -c -o test.o test.c
$ i586-mingw32msvc-gcc -shared -o test.dll test.o
Cannot export HelloWorld: symbol not found
collect2: ld returned 1 exit status
Examining the object file seems to reveal the problem, especially when compared
to the GCC 3.4.5 mingw crosscompiler which is in Debian.
GCC 4.3.0:
$ i586-mingw32msvc-nm test.o | grep HelloWorld
T [EMAIL PROTECTED]
$ strings test.o | grep HelloWorld
-export:HelloWorld
[EMAIL PROTECTED]
GCC 3.4.5:
$ i586-mingw32msvc-nm test.o | grep HelloWorld
T [EMAIL PROTECTED]
$ strings test.o | grep HelloWorld
-export:[EMAIL PROTECTED]
[EMAIL PROTECTED]
Notice the subtle difference in output of the last command. Between 3.4.5 and
4.3.0 the @0 stdcall decoration in the -export:[EMAIL PROTECTED] line got lost,
which makes it impossible to link DLLs with exported stdcall functions.
Here are some details about the compiler versions used for testing:
$ i586-mingw32msvc-gcc-4.3.0 -v
Using built-in specs.
Target: i586-mingw32msvc
Configured with: ../gcc/configure --prefix=/opt/mingw --target=i586-mingw32msvc
--enable-languages=c --disable-multilib --disable-shared --enable-threads=win32
--enable-version-specific-runtime-libs --enable-sjlj-exceptions :
(reconfigured) ../gcc/configure --prefix=/opt/mingw --target=i586-mingw32msvc
--enable-languages=c,c++ --disable-multilib --disable-shared
--enable-threads=win32 --enable-version-specific-runtime-libs
--enable-sjlj-exceptions
Thread model: win32
gcc version 4.3.0 20070424 (experimental)
$ i586-mingw32msvc-gcc-3.4.5 -v
Reading specs from /usr/lib/gcc/i586-mingw32msvc/3.4.5/specs
Configured with:
/build/buildd/mingw32-3.4.5.20060117.1.dfsg/build_dir/src/gcc-3.4.5-20060117-1-dfsg/configure
-v --prefix=/usr --target=i586-mingw32msvc --enable-languages=c,c++
--enable-threads --enable-sjlj-exceptions --disable-multilib
--enable-version-specific-runtime-libs
Thread model: win32
gcc version 3.4.5 (mingw special)
--
Summary: Cannot create DLL with exported stdcall functions
because compiler exports the functions without the @N
decoration
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tobivollebregt at gmail dot com
GCC build triplet: i486-linux-gnu
GCC host triplet: i486-linux-gnu
GCC target triplet: i586-mingw32msvc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31680
[Bug c/31680] Cannot create DLL with exported stdcall functions because compiler exports the functions without the @N decoration
--- Comment #1 from tobivollebregt at gmail dot com 2007-04-24 11:01 --- Created an attachment (id=13434) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13434action=view) Shell script which I used to create the 4.3.0 cross compiler The used binutils are the official binutils. The mingw-runtime and w32-api came from http://sourceforge.net/project/showfiles.php?group_id=2435. Just FYI, the md5sums of the respective files I used, are: e26e2e06b6e4bf3acf1dc8688a94c0d1 binutils-2.17.tar.bz2 a9fdbd5162aa1ae0171c47f929adf938 mingw-runtime-3.12-src.tar.gz be0b0219645a4ee0f3495c2abf90b5ad w32api-3.9-src.tar.gz -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31680
[Bug c/31680] Cannot create DLL with exported stdcall functions because compiler exports the functions without the @N decoration
--- Comment #2 from tobivollebregt at gmail dot com 2007-04-24 11:06 --- Created an attachment (id=13435) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13435action=view) Log of the compiler build. Maybe the most useful line in the log: Checked out revision 124096. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31680
[Bug c++/31598] g++ does not accept some OpenMP code
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | URL||http://gcc.gnu.org/ml/gcc- ||patches/2007- ||04/msg01572.html Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-04-24 11:41:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31598
[Bug libfortran/30617] recursive I/O hangs under OSX
--- Comment #26 from jakub at gcc dot gnu dot org 2007-04-24 11:59 --- Please define fixed. You run an invalid program, all you need is change your expectations what will happen. It is the same as if you write pthread_mutex_t m; pthread_mutex_init (m, NULL); pthread_mutex_lock (m); pthread_mutex_lock (m); The deadlock might be detected or might not, at which point it would hang. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
[Bug target/31674] [4.3 Regression] internal consistency failure on ia64 with -O
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||ice-on-valid-code Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31674
[Bug target/31679] Incorrect result of multiplication long long by 0xFFFFFFFFLL constant.
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-04-24 12:39 --- test.c: In function 'main': test.c:5: warning: incompatible implicit declaration of built-in function 'printf' include stdio.h -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31679
[Bug tree-optimization/30558] ICE with OpenMP and exceptions
--- Comment #7 from jakub at gcc dot gnu dot org 2007-04-24 12:45 ---
Even more reduced testcase:
static int s = 6;
template typename T struct F
{
~F () {}
F (T x) {}
const T operator[] (unsigned i) const { return s; }
};
template typename T FT foo (const FT x)
{
return FT (x[1]);
}
static Fint z = 6;
struct G
{
G () { bar (2); }
Fint operator () (Fint x) { return z; }
void bar (int);
};
int
main ()
{
try
{
G g;
#pragma omp parallel for
for (int i = 0; i 10; ++i)
{
Fint j (i);
Fint f = g (j);
Fint h = foo (f);
}
}
catch (int e)
{
}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30558
[Bug libfortran/30617] recursive I/O hangs under OSX
--- Comment #27 from dominiq at lps dot ens dot fr 2007-04-24 13:03 --- Please define fixed. For me fixed==no hanging period. You run an invalid program, Yes, I know, repeating that won't help! all you need is change your expectations what will happen. Bugzilla has plenty of entries ICE on invalid, I am just asking that hanging on invalid is not brushed aside just because it does happen on a platform some people don't like. It is the same as if you write pthread_mutex_t m; pthread_mutex_init (m, NULL); pthread_mutex_lock (m); pthread_mutex_lock (m); The deadlock might be detected or might not, at which point it would hang. As far as I can tell, without knowledge of the 'pthread_mutex' mechanism, the problem does not occur at this level, but at the level of: pthread_mutex_unlock (m) pthread_mutex_unlock (m) where the first 'unlock' releases all the previous locks dealing with the same unit number, leaving the second 'unlock' waiting for something that is not coming. Something like: pthread_mutex_init (m, NULL); pthread_mutex_lock (m); pthread_mutex_init (m1, NULL); pthread_mutex_lock (m1); ... pthread_mutex_unlock (m1) pthread_mutex_unlock (m) is working (see comment #19), so probably if m refers to some event and not to some unit number (not being ashamed to show my ignorance) the problem would disappear. I think the following answer from http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/d3caadeb9083808e/78c9e65c8b4f930e?lnk=gstq=recursivernum=11#78c9e65c8b4f930e summarize the discussion Even if this restriction on recursive input/output is unnecessary or undesireable, it is, nonetheless, a part of the Fortran 2003 standard. Note the unnecessary or undesireable, leading me to the following comments: (1) the use of recursive I/O can be detected at run time: xlf does it; I guess that a second locking of 'm' would not be too difficult to detect and I don't buy the efficiency argument at this level (gfortran did not strike me as being any faster than xlf on I/O operations); (2) the behavior, however processor (fortran meaning) dependent it is, should be platform independent: just imagine the port to OSX of a 100kloc code where one such recusive I/O used for debuging on Linux (it works) has been left; (3) I repeat that I am not asking for an immediate fix, only that the problem is not forgotten due to the 'invalid' label. Anyway, thanks for the answer. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
[Bug target/31641] [4.1/4.2/4.3 Regression] ICE in s390_expand_setmem, at config/s390/s390.c:3618
--- Comment #4 from krebbel at gcc dot gnu dot org 2007-04-24 13:08 --- Subject: Bug 31641 Author: krebbel Date: Tue Apr 24 13:08:05 2007 New Revision: 124099 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124099 Log: 2007-04-24 Andreas Krebbel [EMAIL PROTECTED] PR target/31641 * config/s390/s390.c (s390_expand_setmem): Don't ICE for constant length argument of 0 for memset. (s390_expand_movmem, s390_expand_setmem, s390_expand_cmpmem): Use unsigned shift instead of the signed variant. 2007-04-24 Andreas Krebbel [EMAIL PROTECTED] PR target/31641 * gcc.c-torture/compile/pr31641.c: New testcase. Modified: trunk/gcc/ChangeLog trunk/gcc/config/s390/s390.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31641
[Bug target/31641] [4.1/4.2/4.3 Regression] ICE in s390_expand_setmem, at config/s390/s390.c:3618
--- Comment #5 from krebbel at gcc dot gnu dot org 2007-04-24 13:15 --- Subject: Bug 31641 Author: krebbel Date: Tue Apr 24 13:15:11 2007 New Revision: 124100 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124100 Log: 2007-04-24 Andreas Krebbel [EMAIL PROTECTED] PR target/31641 * config/s390/s390.c (s390_expand_setmem): Don't ICE for constant length argument of 0 for memset. (s390_expand_movmem, s390_expand_setmem, s390_expand_cmpmem): Use unsigned shift instead of the signed variant. 2007-04-24 Andreas Krebbel [EMAIL PROTECTED] PR target/31641 * gcc.c-torture/compile/pr31641.c: New testcase. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/config/s390/s390.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31641
[Bug target/31679] Incorrect result of multiplication long long by 0xFFFFFFFFLL constant.
--- Comment #2 from vlasenko at bifit dot com dot ua 2007-04-24 13:16
---
Yes, it compiles with warning... so what? The bug is not in the warning. If you
insert #include stdio.h in the top of source the bug reproduces and the
problem will not leave.
ÎÊ, if you want to play in bureaucracy, than here is a source that compiles
without warnings:
int __attribute__((__cdecl__)) printf (const char *, ...);
int main()
{
long long qhat = 1;
long long res = qhat * 0xLL;
printf(res = %llx\n, res);
}
P.S. I simply didn't want to include the source of cygwin's stdio.h, to keep
things simplier for YOU.
--
vlasenko at bifit dot com dot ua changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31679
[Bug target/31641] [4.1/4.2/4.3 Regression] ICE in s390_expand_setmem, at config/s390/s390.c:3618
--- Comment #6 from krebbel at gcc dot gnu dot org 2007-04-24 13:21 --- Subject: Bug 31641 Author: krebbel Date: Tue Apr 24 13:21:22 2007 New Revision: 124101 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124101 Log: 2007-04-24 Andreas Krebbel [EMAIL PROTECTED] PR target/31641 * config/s390/s390.c (s390_expand_setmem): Don't ICE for constant length argument of 0 for memset. (s390_expand_movmem, s390_expand_setmem, s390_expand_cmpmem): Use unsigned shift instead of the signed variant. 2007-04-24 Andreas Krebbel [EMAIL PROTECTED] PR target/31641 * gcc.c-torture/compile/pr31641.c: New testcase. Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/config/s390/s390.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31641
[Bug target/31641] [4.1/4.2/4.3 Regression] ICE in s390_expand_setmem, at config/s390/s390.c:3618
--- Comment #7 from krebbel at gcc dot gnu dot org 2007-04-24 13:23 --- Ulrich approved the patch for 4.1/4.2/4.3. -- krebbel at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31641
[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #91 from jv244 at cam dot ac dot uk 2007-04-24 13:37 --- current (i.e. this morning) mainline seems to miscompile CP2K (tested current CVS of CP2K). The code compiled with '-O3 -ftree-vectorize -ffast-math -march=native' on an opteron segfaults on several regtests. The same code runs fine with other compilers and gfortran if compiled with '-O0 -g -Wall -Wextra'. Also, crashes are in several unrelated locations, so it seems something that might be easy to trigger. Failing testcases include: /QS/regtest-gpw-1/Ar.inp.out /QS/regtest-gpw-1/NO2_lsd.inp.out /QS/regtest-gpw-1/H2O-harris.inp.out /QS/regtest-gapw/H2O-gapw-gth.inp.out /QS/regtest-gpw-1/H2O-MD-harris.inp.out /QS/regtest-gapw/H2O-gapw-all.inp.out /QS/regtest-gapw/H2O-gapwxc-gth.inp.out /QS/regtest-gapw/H2S-gapw.inp.out /QS/regtest-gapw/HF_gapw_all_LB.inp.out /QS/regtest-gapw/OF_gapw_all_lsd_LB.inp.out /QS/regtest-gapw/H-gapw-all.inp.out /QS/regtest-gapw/He2-all.inp.out /QS/regtest-gpw-1/H2O-Harris-Debug-SCF.inp.out /QS/regtest-gpw-3/H+.inp.out : /QS/regtest-gapw/He2-all-md.inp.out /QS/regtest-gapw/CO.inp.out /QS/regtest-gapw/CO_xastphh.inp.out /QS/regtest-gapw/CO_xastpfh.inp.out /QS/regtest-gapw/CO_xastpxhh.inp.out /QS/regtest-gapw/CO_xastpxfh.inp.out /QS/regtest-gapw/CO_xastpval.inp.out /QS/regtest-gapw/Li-ROKS.inp.out I'll see if I can reduce the number of optimization options. -- jv244 at cam dot ac dot uk changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug target/31679] Incorrect result of multiplication long long by 0xFFFFFFFFLL constant.
--- Comment #3 from vlasenko at bifit dot com dot ua 2007-04-24 14:21
---
The bug also reproduces with GCC 4.1.2 compiled under FreeBSD:
gcc -save-temps -v test.c -o test
Using built-in specs.
Target: i386-unknown-freebsd6.0
Configured with: ../gcc-4.1.2/configure --enable-languages=c
--prefix=/usr/local --enable-libmudflap
Thread model: posix
gcc version 4.1.2
/usr/local/libexec/gcc/i386-unknown-freebsd6.0/4.1.2/cc1 -E -quiet -v test.c
-fpch-preprocess -o test.i
ignoring nonexistent directory
/usr/local/lib/gcc/i386-unknown-freebsd6.0/4.1.2/../../../../i386-unknown-freebsd6.0/include
#include ... search starts here:
#include ... search starts here:
/usr/local/include
/usr/local/lib/gcc/i386-unknown-freebsd6.0/4.1.2/include
/usr/include
End of search list.
/usr/local/libexec/gcc/i386-unknown-freebsd6.0/4.1.2/cc1 -fpreprocessed test.i
-quiet -dumpbase test.c -auxbase test -version -o test.s
GNU C version 4.1.2 (i386-unknown-freebsd6.0)
compiled by GNU C version 3.4.4 [FreeBSD] 20050518.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 78c0349a459b0e74d78db4c5d7784698
as -o test.o test.s
/usr/local/libexec/gcc/i386-unknown-freebsd6.0/4.1.2/collect2 -V
-dynamic-linker /libexec/ld-elf.so.1 -o test /usr/lib/crt1.o /usr/lib/crti.o
/usr/local/lib/gcc/i386-unknown-freebsd6.0/4.1.2/crtbegin.o
-L/usr/local/lib/gcc/i386-unknown-freebsd6.0/4.1.2
-L/usr/local/lib/gcc/i386-unknown-freebsd6.0/4.1.2/../../.. test.o -lgcc
-lgcc_eh -lc -lgcc -lgcc_eh
/usr/local/lib/gcc/i386-unknown-freebsd6.0/4.1.2/crtend.o /usr/lib/crtn.o
GNU ld version 2.15 [FreeBSD] 2004-05-23
Supported emulations:
elf_i386_fbsd
test.c:
int __attribute__((__cdecl__)) printf (const char *, ...);
int main()
{
long long qhat = 1;
long long res = qhat * 0xLL;
printf(res = %llx\n, res);
}
output:
res =
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31679
[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #92 from jv244 at cam dot ac dot uk 2007-04-24 14:31 --- (In reply to comment #91) /QS/regtest-gpw-1/NO2_lsd.inp.out I'll see if I can reduce the number of optimization options. the above testcase also fails at a plain '-O2' so I suspect it won't happen only on opteron. Valgrind reports: ==5839== ==5839== Invalid read of size 4 ==5839==at 0x433696: __ai_overlap_new_MOD_overlap (in /scratch/vondele/clean/cp2k/exe/Linux-x86-64-gfortran/cp2k.sopt) ==5839==by 0x9BB779: __qs_core_hamiltonian_MOD_build_core_hamiltonian_matrix (in /scratch/vondele/clean/cp2k/exe/Linux-x86-64-gfortran/cp2k.sopt) ==5839==by 0x9E8834: __qs_energy_MOD_qs_energies (in /scratch/vondele/clean/cp2k/exe/Linux-x86-64-gfortran/cp2k.sopt) ==5839==by 0x9FFE33: __qs_force_MOD_qs_forces (in /scratch/vondele/clean/cp2k/exe/Linux-x86-64-gfortran/cp2k.sopt) ==5839==by 0x606294: __force_env_methods_MOD_force_env_calc_energy_force (in /scratch/vondele/clean/cp2k/exe/Linux-x86-64-gfortran/cp2k.sopt) ==5839==by 0x4B8788: __cp2k_runs_MOD_cp2k_run (in /scratch/vondele/clean/cp2k/exe/Linux-x86-64-gfortran/cp2k.sopt) ==5839==by 0x4B97BB: __cp2k_runs_MOD_run_input (in /scratch/vondele/clean/cp2k/exe/Linux-x86-64-gfortran/cp2k.sopt) ==5839==by 0xD3658A: MAIN__ (in /scratch/vondele/clean/cp2k/exe/Linux-x86-64-gfortran/cp2k.sopt) ==5839==by 0xE6291B: main (fmain.c:22) ==5839== Address 0x1C04DD48 is not stack'd, malloc'd or (recently) free'd ==5839== ==5839== Process terminating with default action of signal 11 (SIGSEGV) ==5839== Access not within mapped region at address 0x1C04DD48 ==5839==at 0x433696: __ai_overlap_new_MOD_overlap (in /scratch/vondele/clean/cp2k/exe/Linux-x86-64-gfortran/cp2k.sopt) ==5839==by 0x9BB779: __qs_core_hamiltonian_MOD_build_core_hamiltonian_matrix (in /scratch/vondele/clean/cp2k/exe/Linux-x86-64-gfortran/cp2k.sopt) ==5839==by 0x9E8834: __qs_energy_MOD_qs_energies (in /scratch/vondele/clean/cp2k/exe/Linux-x86-64-gfortran/cp2k.sopt) ==5839==by 0x9FFE33: __qs_force_MOD_qs_forces (in /scratch/vondele/clean/cp2k/exe/Linux-x86-64-gfortran/cp2k.sopt) ==5839==by 0x606294: __force_env_methods_MOD_force_env_calc_energy_force (in /scratch/vondele/clean/cp2k/exe/Linux-x86-64-gfortran/cp2k.sopt) ==5839==by 0x4B8788: __cp2k_runs_MOD_cp2k_run (in /scratch/vondele/clean/cp2k/exe/Linux-x86-64-gfortran/cp2k.sopt) ==5839==by 0x4B97BB: __cp2k_runs_MOD_run_input (in /scratch/vondele/clean/cp2k/exe/Linux-x86-64-gfortran/cp2k.sopt) ==5839==by 0xD3658A: MAIN__ (in /scratch/vondele/clean/cp2k/exe/Linux-x86-64-gfortran/cp2k but I'm not sure that this is really indicative of the location that gets miscompiled. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug libmudflap/31681] New: [4.3 regression]: Many libmudflap faulures
There are many failures in libmudflap in http://gcc.gnu.org/ml/gcc-testresults/2007-04/msg01222.html === libmudflap tests === Running target unix/-m32 FAIL: libmudflap.c++/pass41-frag.cxx execution test FAIL: libmudflap.c++/pass41-frag.cxx (-static) execution test FAIL: libmudflap.c++/pass41-frag.cxx ( -O) execution test FAIL: libmudflap.c++/pass41-frag.cxx (-O2) execution test FAIL: libmudflap.c++/pass41-frag.cxx (-O3) execution test === libmudflap Summary for unix/-m32 === # of expected passes1821 # of unexpected failures5 Running target unix FAIL: libmudflap.c/pass49-frag.c execution test FAIL: libmudflap.c/pass49-frag.c output pattern test FAIL: libmudflap.c/pass49-frag.c execution test FAIL: libmudflap.c/pass49-frag.c output pattern test FAIL: libmudflap.c/fail8-frag.c (-static) output pattern test FAIL: libmudflap.c/fail9-frag.c (-static) output pattern test FAIL: libmudflap.c/pass49-frag.c (-static) execution test FAIL: libmudflap.c/pass49-frag.c (-static) output pattern test FAIL: libmudflap.c/pass49-frag.c (-static) execution test FAIL: libmudflap.c/pass49-frag.c (-static) output pattern test FAIL: externs-12 execution FAIL: externs-21 execution FAIL: externs-12 execution -static FAIL: externs-21 execution -static FAIL: externs-12 execution -O2 FAIL: externs-21 execution -O2 FAIL: externs-12 execution -O3 FAIL: externs-21 execution -O3 FAIL: libmudflap.c++/pass41-frag.cxx execution test FAIL: libmudflap.c++/pass41-frag.cxx (-static) execution test FAIL: libmudflap.c++/pass41-frag.cxx ( -O) execution test FAIL: libmudflap.c++/pass41-frag.cxx (-O2) execution test FAIL: libmudflap.c++/pass41-frag.cxx (-O3) execution test === libmudflap Summary for unix === # of expected passes1803 # of unexpected failures23 === libmudflap Summary === # of expected passes3624 # of unexpected failures28 -- Summary: [4.3 regression]: Many libmudflap faulures Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libmudflap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31681
[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #93 from jv244 at cam dot ac dot uk 2007-04-24 15:11 --- (In reply to comment #91) I checked that the miscompilation at '-O2' also happens for the sources in the initial comment, so it is definitely a gfortran regression. Furthermore, by recompiling ai_overlap_new.F and qs_core_hamiltonian.F with -O0 the codes passes the point where it segfaulted (to finite a new location to segfault). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug target/31679] Incorrect result of multiplication long long by 0xFFFFFFFFLL constant.
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-04-24 15:17 ---
I can reproduce this on i?86 with 32bit HWI (even with optimization if you
trick around CCP):
int one(void) { return 1; }
int printf (const char *, ...);
int main()
{
long long qhat = one();
long long res = qhat * 0xLL;
printf(res = %llx\n, res);
return 0;
}
But only with 4.1.1, at least gcc (GCC) 4.1.3 20070413 and
gcc (GCC) 4.1.2 20061115 (prerelease) are ok. Also
some gcc (GCC) 4.1.0 (SUSE Linux) is ok.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
GCC build triplet|i686-pc-cygwin |
GCC host triplet|i686-pc-cygwin |
GCC target triplet|i686-pc-cygwin |i686-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31679
[Bug libgomp/31682] New: [4.3 regression]: Many libgomp failures
There are many libgomp failures in http://gcc.gnu.org/ml/gcc-testresults/2007-04/msg01222.html === libgomp tests === Running target unix/-m32 === libgomp Summary for unix/-m32 === # of expected passes1566 Running target unix FAIL: libgomp.fortran/vla1.f90 -O1 execution test FAIL: libgomp.fortran/vla1.f90 -O2 execution test FAIL: libgomp.fortran/vla1.f90 -O3 -fomit-frame-pointer execution test FAIL: libgomp.fortran/vla1.f90 -O3 -fomit-frame-pointer -funroll-loops execution test FAIL: libgomp.fortran/vla1.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test FAIL: libgomp.fortran/vla1.f90 -O3 -g execution test FAIL: libgomp.fortran/vla1.f90 -Os execution test FAIL: libgomp.fortran/vla2.f90 -O1 execution test FAIL: libgomp.fortran/vla2.f90 -O2 execution test FAIL: libgomp.fortran/vla2.f90 -O3 -fomit-frame-pointer execution test FAIL: libgomp.fortran/vla2.f90 -O3 -fomit-frame-pointer -funroll-loops execution test FAIL: libgomp.fortran/vla2.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test FAIL: libgomp.fortran/vla2.f90 -O3 -g execution test FAIL: libgomp.fortran/vla3.f90 -O1 execution test FAIL: libgomp.fortran/vla3.f90 -O2 execution test FAIL: libgomp.fortran/vla3.f90 -O3 -fomit-frame-pointer execution test FAIL: libgomp.fortran/vla3.f90 -O3 -fomit-frame-pointer -funroll-loops execution test FAIL: libgomp.fortran/vla3.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test FAIL: libgomp.fortran/vla3.f90 -O3 -g execution test FAIL: libgomp.fortran/vla4.f90 -O1 execution test FAIL: libgomp.fortran/vla4.f90 -O2 execution test FAIL: libgomp.fortran/vla4.f90 -O3 -fomit-frame-pointer execution test FAIL: libgomp.fortran/vla4.f90 -O3 -fomit-frame-pointer -funroll-loops execution test FAIL: libgomp.fortran/vla4.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test FAIL: libgomp.fortran/vla4.f90 -O3 -g execution test FAIL: libgomp.fortran/vla4.f90 -Os execution test FAIL: libgomp.fortran/vla5.f90 -O1 execution test FAIL: libgomp.fortran/vla5.f90 -O2 execution test FAIL: libgomp.fortran/vla5.f90 -O3 -fomit-frame-pointer execution test FAIL: libgomp.fortran/vla5.f90 -O3 -fomit-frame-pointer -funroll-loops execution test FAIL: libgomp.fortran/vla5.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test FAIL: libgomp.fortran/vla5.f90 -O3 -g execution test FAIL: libgomp.fortran/vla5.f90 -Os execution test FAIL: libgomp.fortran/vla6.f90 -O1 execution test FAIL: libgomp.fortran/vla6.f90 -O2 execution test FAIL: libgomp.fortran/vla6.f90 -O3 -fomit-frame-pointer execution test FAIL: libgomp.fortran/vla6.f90 -O3 -fomit-frame-pointer -funroll-loops execution test FAIL: libgomp.fortran/vla6.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test FAIL: libgomp.fortran/vla6.f90 -O3 -g execution test === libgomp Summary for unix === # of expected passes1527 # of unexpected failures39 === libgomp Summary === # of expected passes3093 # of unexpected failures39 -- Summary: [4.3 regression]: Many libgomp failures Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31682
[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #94 from jv244 at cam dot ac dot uk 2007-04-24 15:27 --- In fact, gfortran gives a hint here. The file that gets miscompiled produces the following warnings: cp2k/obj/Linux-x86-64-gfortran/sdbg gfortran -c -O2 -g -Wall -Wextra ai_overlap_new.f90 ai_overlap_new.f90: In function overlap: ai_overlap_new.f90:60: warning: offset.8 may be used uninitialized in this function ai_overlap_new.f90:60: warning: stride.7 may be used uninitialized in this function ai_overlap_new.f90:60: warning: stride.5 may be used uninitialized in this function ai_overlap_new.f90:60: warning: pab.0 may be used uninitialized in this function ai_overlap_new.f90:60: warning: offset.16 may be used uninitialized in this function ai_overlap_new.f90:60: warning: stride.15 may be used uninitialized in this function ai_overlap_new.f90:60: warning: stride.13 may be used uninitialized in this function ai_overlap_new.f90:60: warning: stride.11 may be used uninitialized in this function ai_overlap_new.f90:60: warning: sdab.0 may be used uninitialized in this function -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug fortran/31683] New: bogus warnings / miscompilation
The following generates bogus warnings and is likely miscompiled: MODULE test IMPLICIT NONE INTEGER, PARAMETER :: dp=KIND(0.0D0) INTEGER, ALLOCATABLE, DIMENSION(:) :: ncoset PRIVATE PUBLIC :: overlap CONTAINS SUBROUTINE overlap(la_max_set,la_min_set, lb_max_set,lb_min_set, s,lds, pab,force_a) INTEGER, INTENT(IN) :: la_max_set, la_min_set INTEGER, INTENT(IN) :: lb_max_set, lb_min_set INTEGER, INTENT(IN) :: lds REAL(KIND=dp), DIMENSION(lds, lds, *), INTENT(INOUT) :: s REAL(KIND=dp), DIMENSION(:, :), INTENT(IN), OPTIONAL :: pab REAL(KIND=dp), DIMENSION(3), INTENT(OUT), OPTIONAL :: force_a INTEGER :: i, j, k, na, nb LOGICAL :: calculate_force_a ! --- na = 0 nb = 0 calculate_force_a=.TRUE. IF (calculate_force_a) THEN DO k=1,3 DO j=ncoset(lb_min_set-1)+1,ncoset(lb_max_set) DO i=ncoset(la_min_set-1)+1,ncoset(la_max_set) force_a(k) = force_a(k) + pab(na+i,nb+j)*s(i,j,k+1) END DO END DO END DO END IF END SUBROUTINE END MODULE test gfortran -c -O2 -g -Wall test.f90 test.f90: In function overlap: test.f90:7: warning: offset.4 may be used uninitialized in this function test.f90:7: warning: stride.3 may be used uninitialized in this function test.f90:7: warning: stride.1 may be used uninitialized in this function test.f90:7: warning: pab.0 may be used uninitialized in this function it is a reduced testcase from CP2K -- Summary: bogus warnings / miscompilation Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31683
[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #95 from jv244 at cam dot ac dot uk 2007-04-24 15:42 --- added PR 31683 with a reduced testcase -- jv244 at cam dot ac dot uk changed: What|Removed |Added BugsThisDependsOn||31683 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug libfortran/30617] recursive I/O hangs under OSX
--- Comment #28 from pinskia at gcc dot gnu dot org 2007-04-24 15:46 --- Bugzilla has plenty of entries ICE on invalid, I am just asking that hanging on invalid is not brushed aside just because it does happen on a platform some people don't like. It is hanging on undefined, I think there is a difference here, a big difference. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
[Bug libfortran/30617] recursive I/O hangs under OSX
--- Comment #29 from dominiq at lps dot ens dot fr 2007-04-24 15:59 --- It is hanging on undefined, I think there is a difference here, a big difference. What is the difference for you? Just as a side note, that's not me who classed the PR as invalid and so far I did not see a class ICE on undefined. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
[Bug target/31684] New: [4.3 Regression] ICE in get_attr_first_insn, at config/ia64/itanium2.md:1839 at -O2
I get the following ICE with current gcc 4.3. This goes back until at
least 4.3 20070303. 4.1 works. I cannot test 4.2.
[EMAIL PROTECTED]:~$ /usr/lib/gcc-snapshot/bin/gcc -c -O2 mpfr-mul.c
mpfr-mul.c: In function 'mpfr_mul':
mpfr-mul.c:19: error: unrecognizable insn:
(insn:TI 69 102 68 3 (parallel [
(set (reg:DI 136 f8)
(asm_operands:DI (xma.hu %0 = %2, %3, f0
xma.l %1 = %2, %3, f0) (=f) 0 [
(reg:DI 137 f9)
(reg:DI 134 f6 [orig:345 D.1826 ] [345])
]
[
(asm_input:DI (f) () 0)
(asm_input:DI (f) () 0)
] (mpfr-mul.c) 16))
(set (reg/v:DI 135 f7 [orig:340 t3 ] [340])
(asm_operands:DI (xma.hu %0 = %2, %3, f0
xma.l %1 = %2, %3, f0) (=f) 1 [
(reg:DI 137 f9)
(reg:DI 134 f6 [orig:345 D.1826 ] [345])
]
[
(asm_input:DI (f) () 0)
(asm_input:DI (f) () 0)
] (mpfr-mul.c) 16))
]) -1 (nil)
(nil))
mpfr-mul.c:19: internal compiler error: in get_attr_first_insn, at
config/ia64/itanium2.md:1839
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
For Debian GNU/Linux specific bug reporting instructions,
see URL:file:///usr/share/doc/gcc-4.1/README.Bugs.
[EMAIL PROTECTED]:~$ /usr/lib/gcc-snapshot/bin/gcc -c -O mpfr-mul.c
[EMAIL PROTECTED]:~$ gcc-4.1 -c -O2 mpfr-mul.c
[EMAIL PROTECTED]:~$
Testcase:
typedef struct
{
unsigned long int *_mpfr_d;
}
__mpfr_struct;
typedef const __mpfr_struct *mpfr_srcptr;
mpfr_mul (mpfr_srcptr b, mpfr_srcptr c)
{
unsigned long int *tmp;
unsigned long int t1, t2, t3;
unsigned long int __x;
__x = tmp[1] + t1;
tmp[1] = __x;
__asm__ (xma.hu %0 = %2, %3, f0\n\txma.l %1 = %2, %3, f0: =f (t1), =f
(t2):f (((b)-_mpfr_d)[0]),
f (((c)-_mpfr_d)[1]));
__asm__ (xma.hu %0 = %2, %3, f0\n\txma.l %1 = %2, %3, f0: =f (tmp[3]),
=f (t3):f (((b)-_mpfr_d)[1]),
f (((c)-_mpfr_d)[1]));
tmp[3] += t1;
}
--
Summary: [4.3 Regression] ICE in get_attr_first_insn, at
config/ia64/itanium2.md:1839 at -O2
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tbm at cyrius dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31684
[Bug c++/31685] New: [4.3 regression] ICE in set_mem_attributes
// { dg-do compile }
// { dg-options -O2 }
template typename T struct F
{
~F () {}
F (T x) {}
};
template typename T FT foo (const FT x)
{
return x;
}
static Fint z = 6;
struct G
{
G () {}
Fint operator () (Fint x) { return z; }
};
int
main ()
{
G g;
Fint j (0);
Fint f = g (j);
Fint h = foo (f);
}
ICEs on both x86_64-linux and i686-linux in set_mem_attributes_minus_bitpos:
1557 gcc_assert (!(base_type TYPE_NEEDS_CONSTRUCTING
(base_type))
1558 || DECL_ARTIFICIAL (base));
base_type here needs constructing (it is variable z).
Compiles just fine with 4.1.x or 4.2.x.
--
Summary: [4.3 regression] ICE in set_mem_attributes
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31685
[Bug rtl-optimization/31686] New: wrong codegen from reload
See failing test, analysis, suggested patch here: http://gcc.gnu.org/ml/gcc-patches/2007-04/msg01595.html -- Summary: wrong codegen from reload Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hm dot chang at apple dot com GCC build triplet: i386-apple-darwin8 GCC host triplet: i386-apple-darwin8 GCC target triplet: i386-apple-darwin8 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31686
[Bug tree-optimization/30558] ICE with OpenMP and exceptions
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | URL||http://gcc.gnu.org/ml/gcc- ||patches/2007- ||04/msg01601.html Status|NEW |ASSIGNED Last reconfirmed|2007-01-23 23:46:37 |2007-04-24 18:04:40 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30558
[Bug fortran/31683] bogus warnings / miscompilation
--- Comment #1 from burnus at gcc dot gnu dot org 2007-04-24 18:46 --- This example is not valid. As NAG f95 claims: Error: foo.f90, line 45: ALLOCATABLE array NCOSET used but never ALLOCATEd (gfortran actually misses such an error/warning. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31683
[Bug fortran/31683] bogus warnings / miscompilation
--- Comment #2 from jv244 at cam dot ac dot uk 2007-04-24 19:07 --- (In reply to comment #1) This example is not valid. As NAG f95 claims: it is not supposed to be a runable example, of course. Just remove the 'PRIVATE' from the module definition. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31683
[Bug ada/31687] New: gnat incorrectly finds its libraries through symlinks
while the gcc executables reliably find their associated files / libraries / paths even if the executable is invoked through symlinks, this is not true for the gnat executables. For example, if gcc is installed with --prefix=/usr/local/gcc1 and then symlinks are made such as cd /usr/local/bin ; ln -s /usr/local/gcc1/bin/* . with /usr/local/bin in the PATH, gcc will work, gnat not, and for example a bootstrap of gcc will fail for ada (maybe things like bug #24030 are related to this?) Probably, the ada executables don't follow their symlinks path to the last dir and then look for ../lib, but directly look for it (/usr/local/bin/../lib resolving to /usr/local/lib in the above example, instead of finding out that /usr/local/bin/gnat is in /usr/local/gcc/bin/gnat, then getting the library path as /usr/local/gcc/lib/... Workaround: either set the ADA_LIBRARY.. etc env variables to the final directories, or better also make the corresponding library links in the directories expected by gnat (cd /usr/local/lib ; ln -s /usr/local/gcc1/lib/* . ) but resolving the problem in gnat itself would be better. -- Summary: gnat incorrectly finds its libraries through symlinks Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: anirkko at insel dot ch GCC build triplet: sparc-sun-solaris2.6 GCC host triplet: sparc-sun-solaris2.6 GCC target triplet: sparc-sun-solaris2.6 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31687
[Bug middle-end/31688] New: Bogus may be used uninitialized warning
[Based on PR 31683] Compiling the following program with gfortran -O -Wall gives the bogus warning: foo2.f90:4: warning: 'offset.7' may be used uninitialized in this function foo2.f90:4: warning: 'stride.6' may be used uninitialized in this function foo2.f90:4: warning: 'pab.0' may be used uninitialized in this function However, this part of code is not reachable if uninitialized. The code is essentially: int offset.7; if(pab != 0B) offset.7 = -stride.6; if (pab == 0B) return; *force_a = (*pab.0)[offset.7] Full Fortran source: MODULE test IMPLICIT NONE CONTAINS SUBROUTINE overlap(s, lds, pab, force_a) INTEGER, INTENT(IN) :: lds REAL, DIMENSION(lds, lds, *), INTENT(INOUT) :: s REAL, DIMENSION(:), INTENT(IN), OPTIONAL:: pab REAL, INTENT(OUT) :: force_a if(.not.present(pab)) return force_a = pab(1)*s(1,1,1) END SUBROUTINE END MODULE test -- Summary: Bogus may be used uninitialized warning Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: middle-end 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=31688
[Bug fortran/31683] bogus warnings / miscompilation
--- Comment #3 from burnus at gcc dot gnu dot org 2007-04-24 19:58 --- This example is not valid. As NAG f95 claims: it is not supposed to be a runable example Well, for hunting miscompilation bugs, a runable example helps. I think there are at leastfour problems: a) The program misses something like: allocate(ncoset(lb_min_set-1:lb_max_set)) ncoset = 1 - or as you have suggested - overlap may not be PRIVATE otherwise the program is it not valid. b) Since the program is invalid if pad is not present, I added: if(.not.present(pab)) return (similarly for force_a) c) gfortran should detect that the local variable ncoset is never allocated - as NAG f95 does: Error: foo.f90, line 45: ALLOCATABLE array NCOSET used but never ALLOCATEd d) gfortran give the wrong warning about offset.9 being uninitialized. It is initialized if pad is present and if it isn't, this variable is not accessed as I explicitly use: if(.not.present(pab)) return For (d) I filled the middle-end PR 31688. I still miss the place where gfortran miscompiles (if any). -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31683
[Bug middle-end/31688] Bogus may be used uninitialized warning
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-04-24 20:05 --- This is really the oldest uninitialized variable warning bug out there. PR 5035. *** This bug has been marked as a duplicate of 5035 *** -- 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=31688
[Bug tree-optimization/5035] Incorrectly produces '`var' might be used uninitialized in this function'
--- Comment #16 from pinskia at gcc dot gnu dot org 2007-04-24 20:05 --- *** Bug 31688 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5035
[Bug c/31689] New: Support defining attributes at a scope level
Support defining attributes at a scope level.
I'd like to request implementing the feature of defining attributes at a scope
level. For example, allow a syntax such as the following, possibly as a GNU
extension:
if (something)
__attribute__ ((section(bar))) {
/* body of if-statement */
}
...which will place the body of the if-statement in a separate memory region.
The motivation behind this request is the need to place uncommonly used code in
a separate memory region for better cache locality. For example, given a piece
of C code such as the following:
if (something) {
/* body */
}
... we need to place the entire body in a separate memory region.
1 -- Attempting to use extended inline assembly to implement this is
problematic since the general assumption is that outbound/inbound branches are
not allowed in inline assembly. As Jim Wilson also notes, using Labels as
values (e.g. label) confuses the CFG, effectively disabling some
optimizations, which means that performance may be lost when doing this
(http://lists.gnu.org/archive/html/bug-binutils/2007-04/msg00120.html).
Additionally, trying to do things behind the compilers back (in inline
assembly) will not work in the long-term.
2 -- Using the section attribute to place an entire function in a separate
region is also unsuitable. For example a definition such as:
extern void foobar (void) __attribute__ ((section (bar)));
puts the entire function `foobar' in the `bar' section, not just the body of an
if statement inside the function. Additionally, putting the body of the
if-statement in a separate function and defining that function to be in a
separate section is not adequate. If the body of the if-statement contains
return instructions or gotos to other parts of the function, won't permit
returning to the function caller or other parts of the original function
(http://gcc.gnu.org/ml/gcc-help/2007-04/msg00282.html).
Discussions about this topic are listed in:
http://gcc.gnu.org/ml/gcc-help/2007-04/msg00250.html
http://lists.gnu.org/archive/html/bug-binutils/2007-04/msg00107.html
--
Summary: Support defining attributes at a scope level
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mkgnu at mkgnu dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31689
[Bug c/31689] Support defining attributes at a scope level
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-04-24 20:27 --- This is a stupid idea, it is better to use __builtin_expect and -freorder-blocks-and-partition which means this is a dup of bug 26493. *** This bug has been marked as a duplicate of 26493 *** -- 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=31689
[Bug rtl-optimization/26493] -freorder-blocks-and-partition is a dud without generated profiling data
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-04-24 20:27 --- *** Bug 31689 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||mkgnu at mkgnu dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26493
[Bug fortran/31668] %VAL rejected for PROC_MODULE and PROC_INTERNAL procedures
--- Comment #1 from steven at gcc dot gnu dot org 2007-04-24 20:31 --- Patch posted here: http://gcc.gnu.org/ml/gcc-patches/2007-04/msg01609.html -- steven at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2007- ||04/msg01609.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31668
[Bug fortran/31683] bogus warnings with optional arguments
--- Comment #4 from tkoenig at gcc dot gnu dot org 2007-04-24 21:06 ---
There is a questionable practice with the original code: It uses
pab without a check whether it is present.
The compiler tries to guard against this, partially by generating
(from the *.original dump):
if (pab != 0B)
{
{
int4 D.1054;
D.1054 = pab-dim[0].stride;
stride.1 = D.1054 == 0 ? 1 : D.1054;
pab.0 = (real8[0:D.1055] *) pab-data;
ubound.0 = (pab-dim[0].ubound - pab-dim[0].lbound) + 1;
stride.3 = pab-dim[1].stride;
ubound.2 = (pab-dim[1].ubound - pab-dim[1].lbound) + 1;
size.5 = stride.3 * NON_LVALUE_EXPR ubound.2;
offset.4 = -stride.1 - NON_LVALUE_EXPR stride.3;
D.1055 = size.5 - 1;
D.1056 = (bit_size_type) (unnamed-unsigned:32) size.5 * 64;
D.1057 = (unnamed-unsigned:32) size.5 * 8;
}
}
All these variables are initialized in this block, and nowhere
else. Later in the loop, they are used, which generates the warnings.
The if(pab) above doesn't really help because the code will crash, or produce
strange results, if pab isn't present.
This is a very misleading diagnostic, but not a wrong-code as far as I can see.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||diagnostic
Last reconfirmed|-00-00 00:00:00 |2007-04-24 21:06:01
date||
Summary|bogus warnings /|bogus warnings with optional
|miscompilation |arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31683
Equivalence bug in gfortran
Sorry to bother you, but I am too stupid to understand how to use bugzilla. So I send this bug report via the way of last resort. The following does not link. module bla logical, save :: blub= .true. logical :: pa equivalence (blub, pa) end module program po use bla, only : pa write (*,*) pa end program po ! gfortran Equivalence-Bug.f90 -static ! /tmp/UserName/ccOoVp3X.o: In function `MAIN__': ! Equivalence-Bug.f90:(.text+0x61): undefined reference to `__bla__pa' ! collect2: ld returned 1 exit status Cordially, Warner
[Bug tree-optimization/30567] [4.2 Regression] -O3 optimizer bug
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30567
[Bug tree-optimization/31605] [4.2/4.3 Regression] VRP eliminates a useful test due with conversion from unsigned int to int
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31605
[Bug tree-optimization/31602] Overflow warning causes GDB -Werror build failure
--- Comment #5 from ian at gcc dot gnu dot org 2007-04-24 21:44 --- Subject: Bug 31602 Author: ian Date: Tue Apr 24 21:44:45 2007 New Revision: 124120 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124120 Log: ./: PR tree-optimization/31602 * tree-ssa-loop-ch.c (copy_loop_headers): Set TREE_NO_WARNING for conditionals in the copied loop header. * tree-cfg.c (fold_cond_expr_cond): Don't issue undefined overflow warnings if TREE_NO_WARNING is set. * doc/invoke.texi (Warning Options): Clarify that -Wstrict-overflow does not warn about loops. testsuite/: PR tree-optimization/31602 * gcc.dg/Wstrict-overflow-11.c: We no longer issue a warning. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/invoke.texi trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/Wstrict-overflow-11.c trunk/gcc/tree-cfg.c trunk/gcc/tree-ssa-loop-ch.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31602
[Bug debug/31690] New: ICE with const __uint128_t and C++ front-end
Testcase, compile with -g: const __uint128_t fives = (((__uint128_t)(0xULL)) 64)|((__uint128_t)(0xULL)); The ICE on the mainline: t.c:0: internal compiler error: in add_const_value_attribute, at dwarf2out.c:10005 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. -- Summary: ICE with const __uint128_t and C++ front-end Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: debug AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org GCC target triplet: powerpc64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31690
[Bug fortran/25923] [gfortran] garbled diagnostics with -O -Wuninitialized
--- Comment #5 from simartin at gcc dot gnu dot org 2007-04-24 21:52 --- Subject: Bug 25923 Author: simartin Date: Tue Apr 24 21:52:16 2007 New Revision: 124121 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124121 Log: 2007-04-24 Simon Martin [EMAIL PROTECTED] PR diagnostic/25923 * tree-pass.h (TDF_DIAGNOSTIC): New dump control to specify that a diagnostic message is being built. * tree-pretty-print.c (dump_generic_node): Only write the formatted text into BUFFER's stream if we are not building a diagnostic message. * toplev.c (default_tree_printer): Pass TDF_DIAGNOSTIC to dump_generic_node. * Makefile.in (toplev.o): Depend on tree-pass.h. Added: trunk/gcc/testsuite/gfortran.dg/pr25923.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in trunk/gcc/testsuite/ChangeLog trunk/gcc/toplev.c trunk/gcc/tree-pass.h trunk/gcc/tree-pretty-print.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25923
[Bug c/31691] New: optimized code taking the wrong branch
The following example takes the wrong_branch when compiled with
gcc -O3 -fno-inline
gcc --version
gcc (GCC) 4.1.2
Copyright (C) 2006 Free Software Foundation, Inc.
= example =
#include stdio.h
static int get_kind(int v) {
volatile int k = v;
return k;
}
static int some_call(void)
{
return 0;
}
static void wrong_branch(void) {
printf(wrong_branch\n);
}
static int example(int arg)
{
int kind;
kind = get_kind(arg);
if (kind == 9 || kind == 10 || kind == 5) {
if (some_call() == 0) {
int tmp;
//kind = get_kind(arg); // ok if this call is inserted
if (kind == 9 || kind == 10) {
tmp = arg;
} else {
wrong_branch();
} /* if */
return 0;
}
}
return 0;
}
int main(void) {
int v = 10;
example(v);
return 0;
}
===
The example prints wrong_branch when executed. If the second call to get_kind
is uncommented, nothing is printed (which is correct).
The generated assembly code is
= example.s ==
example:
save%sp, -112, %sp
callget_kind, 0
mov%i0, %o0
add %o0, -9, %g1
subcc %g0, %g1, %g0
subx%g0, -1, %i0
cmp %g1, 1
bleu.LL11
cmp%o0, 5
be .LL11
nop
.LL9:
jmp %i7+8
restore %g0, 0, %o0
.LL11:
callsome_call, 0
nop
cmp %o0, 0
bne .LL9
cmp%i0, 0
bne .LL9
nop
callwrong_branch, 0
mov0, %i0
jmp %i7+8
restore
===
--
Summary: optimized code taking the wrong branch
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: stephaniechc-gccbug at yahoo dot com
GCC build triplet: sparc-sun-solaris2.8
GCC host triplet: sparc-sun-solaris2.8+
GCC target triplet: sparc-sun-solaris2.8+
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31691
[Bug fortran/31587] Module files shouldn't be updated if their content doesn't change
--- Comment #13 from fxcoudert at gcc dot gnu dot org 2007-04-24 22:37 --- Subject: Bug 31587 Author: fxcoudert Date: Tue Apr 24 22:37:37 2007 New Revision: 124126 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124126 Log: PR fortran/31587 * lib/gcc-dg.exp (scan-module): New function. * gfortran.dg/module_md5_1.f90: New test. * module.c (write_char): Add character to the MD5 buffer. (read_md5_from_module_file): New function. (gfc_dump_module): Compute MD5 for new module file. Call read_md5_from_module_file. Only overwrite old module file if the new MD5 is different. Added: trunk/gcc/testsuite/gfortran.dg/module_md5_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/module.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/lib/gcc-dg.exp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31587
[Bug fortran/31587] Module files shouldn't be updated if their content doesn't change
--- Comment #14 from fxcoudert at gcc dot gnu dot org 2007-04-24 22:38 --- Fixed on mainline. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31587
[Bug rtl-optimization/31360] [4.2 Regression] rtl loop invariant is broken
--- Comment #17 from mmitchel at gcc dot gnu dot org 2007-04-24 22:42 --- Zdenek, do you think this is appropriate for a backport to 4.2.0? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31360
[Bug target/30222] [4.2 Regression] gcc.target/i386/vectorize1.c ICEs
--- Comment #6 from mmitchel at gcc dot gnu dot org 2007-04-24 22:43 --- Andrew, can you identify whatever portion of this patch has not yet been applied to 4.2? -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30222
[Bug rtl-optimization/31360] [4.2 Regression] rtl loop invariant is broken
--- Comment #18 from pinskia at gcc dot gnu dot org 2007-04-24 22:44 --- (In reply to comment #17) Zdenek, do you think this is appropriate for a backport to 4.2.0? Well right now it causes a regression so I don't think it is appropriate until that regression is fixed :). See PR 31676 for the regression. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31360
[Bug middle-end/30761] [4.1/4.2 regression] Error: unsupported relocation against sfp
--- Comment #8 from mmitchel at gcc dot gnu dot org 2007-04-24 22:46 --- Ulrich, in response to your question in Comment #6, yes, this bug appears in 4.1 and 4.2, not just in 4.3. So, if you think it's safe to backport the reload patch, it would be nice to have the fix there as well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30761
[Bug target/26792] [4.2 Regression] need to use autoconf when using newly-added libgcc functions
--- Comment #33 from mmitchel at gcc dot gnu dot org 2007-04-24 22:51 --- Geoff, do you intend to backport these Darwin patches to 4.2.0? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26792
[Bug tree-optimization/31602] Overflow warning causes GDB -Werror build failure
--- Comment #6 from ian at gcc dot gnu dot org 2007-04-24 22:54 --- Subject: Bug 31602 Author: ian Date: Tue Apr 24 22:54:22 2007 New Revision: 124127 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124127 Log: PR tree-optimization/31602 * tree-ssa-loop-ch.c (copy_loop_headers): Set TREE_NO_WARNING for conditionals in the copied loop header. * tree-cfg.c (fold_cond_expr_cond): Don't issue undefined overflow warnings if TREE_NO_WARNING is set. * doc/invoke.texi (Warning Options): Clarify that -Wstrict-overflow does not warn about loops. Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/doc/invoke.texi branches/gcc-4_2-branch/gcc/tree-cfg.c branches/gcc-4_2-branch/gcc/tree-ssa-loop-ch.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31602
[Bug tree-optimization/31605] [4.2/4.3 Regression] VRP eliminates a useful test due with conversion from unsigned int to int
--- Comment #6 from ian at gcc dot gnu dot org 2007-04-24 23:24 --- Subject: Bug 31605 Author: ian Date: Tue Apr 24 23:24:01 2007 New Revision: 124128 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124128 Log: ./: PR tree-optimization/31605 * tree-vrp.c (set_value_range): Check that min and max are not both overflow infinities. (set_value_range_to_value): New static function. (extract_range_from_binary_expr): Call set_value_range_to_value. (extract_range_from_cond_expr): Likewise. (extract_range_from_expr): Likewise. (extract_range_from_unary_expr): Likewise. Don't create a range which overflows on both sides. (vrp_meet): Check for a useless range. (vrp_visit_phi_node): If we see a constant which looks like an overflow infinity, turn off the TREE_OVERFLOW flag. testsuite/: PR tree-optimizatoin/31605 * gcc.c-torture/execute/pr31605.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr31605.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vrp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31605
[Bug tree-optimization/31605] [4.2/4.3 Regression] VRP eliminates a useful test due with conversion from unsigned int to int
--- Comment #7 from ian at gcc dot gnu dot org 2007-04-24 23:26 --- Subject: Bug 31605 Author: ian Date: Tue Apr 24 23:26:25 2007 New Revision: 124129 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124129 Log: ./ChangeLog: PR tree-optimization/31605 * tree-vrp.c (set_value_range): Check that min and max are not both overflow infinities. (set_value_range_to_value): New static function. (extract_range_from_binary_expr): Call set_value_range_to_value. (extract_range_from_expr): Likewise. (extract_range_from_unary_expr): Likewise. Don't create a range which overflows on both sides. (vrp_meet): Check for a useless range. (vrp_visit_phi_node): If we see a constant which looks like an overflow infinity, turn off the TREE_OVERFLOW flag. testsuite/ChangeLog: PR tree-optimization/31605 * gcc.c-torture/execute/pr31605.c: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/gcc.c-torture/execute/pr31605.c Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/testsuite/ChangeLog branches/gcc-4_2-branch/gcc/tree-vrp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31605
[Bug tree-optimization/31602] Overflow warning causes GDB -Werror build failure
--- Comment #7 from ian at airs dot com 2007-04-24 23:27 --- Fixed on mainline and 4.2 branch. -- ian at airs dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31602
[Bug tree-optimization/31605] [4.2/4.3 Regression] VRP eliminates a useful test due with conversion from unsigned int to int
--- Comment #8 from ian at airs dot com 2007-04-24 23:28 --- Fixed on mainline and 4.2 branch. -- ian at airs dot com changed: What|Removed |Added Status|NEW |RESOLVED Priority|P1 |P3 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31605
[Bug c++/30500] pragma GCC system_header vs templates
--- Comment #6 from paolo at gcc dot gnu dot org 2007-04-24 23:37 --- Subject: Bug 30500 Author: paolo Date: Tue Apr 24 23:36:53 2007 New Revision: 124130 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124130 Log: 2007-04-24 Paolo Carlini [EMAIL PROTECTED] PR c++/30500 * pt.c (instantiate_decl): Set in_system_header. 2007-04-24 Paolo Carlini [EMAIL PROTECTED] PR c++/30500 * g++.dg/warn/pragma-system_header3.C: New test. * g++.dg/warn/pragma-system_header3.h. New. Added: branches/gcc-4_2-branch/gcc/testsuite/g++.dg/warn/pragma-system_header3.C branches/gcc-4_2-branch/gcc/testsuite/g++.dg/warn/pragma-system_header3.h Modified: branches/gcc-4_2-branch/gcc/cp/ChangeLog branches/gcc-4_2-branch/gcc/cp/pt.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30500
[Bug c++/30500] pragma GCC system_header vs templates
-- pcarlini at suse dot de changed: What|Removed |Added Target Milestone|4.3.0 |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30500
[Bug libstdc++/31638] [4.0/4.1 Regression] string usage leads to warning with -Wcast-align
--- Comment #8 from pcarlini at suse dot de 2007-04-24 23:39 --- Problem solved in 4_2-branch too via fixing C++/30500. Nothing will be done in older branches. -- pcarlini at suse dot de changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Summary|[4.0/4.1/4.2 Regression]|[4.0/4.1 Regression] string |string usage leads to |usage leads to warning with |warning with -Wcast-align |-Wcast-align http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31638
Symbol ALERT
General
[Bug libstdc++/31638] [4.0/4.1 Regression] string usage leads to warning with -Wcast-align
-- pcarlini at suse dot de changed: What|Removed |Added Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31638
