Re: Why is this a problem in the C++ bootstrap and not the normal one ?
Toon Moene wrote: On 05/11/2011 02:58 PM, Toon Moene wrote: My C++-fu is pretty non-existent; I tried a C++ bootstrap and got this: http://gcc.gnu.org/ml/gcc-testresults/2011-05/msg01129.html Why is that a problem in the C++ bootstrap and not the normal one ? For completeness, the message is generated by the attached script, run by cron at 18:10 UTC. The build is a native one on x86_64-unknown-linux-gnu. I thought that adding --disable-werror would bring us further, but as it turns out - not by much: http://gcc.gnu.org/ml/gcc-testresults/2011-05/msg01224.html says: /home/toon/compilers/obj-t/./prev-gcc/g++ -B/home/toon/compilers/obj-t/./prev-gcc/ -B/tmp/c++/x86_64-unknown-linux-gnu/bin/ -nostdinc++ -B/home/toon/compilers/obj-t/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -I/home/toon/compilers/obj-t/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/home/toon/compilers/obj-t/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include -I/home/toon/compilers/gcc/libstdc++-v3/libsupc++ -L/home/toon/compilers/obj-t/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -c -g -O2 -gtoggle -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -Iobjc -I../../gcc/gcc -I../../gcc/gcc/objc -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/bid -I../libdecnumber ../../gcc/gcc/objc/objc-next-runtime-abi-02.c -o objc/objc-next-runtime-abi-02.o ../../gcc/gcc/objc/objc-next-runtime-abi-02.c: In function 'const char* newabi_append_ro(const char*)': ../../gcc/gcc/objc/objc-next-runtime-abi-02.c:1885:29: error: invalid conversion from 'const char*' to 'char*' [-fpermissive] I have to see if it is useful to keep on testing the C++ bootstrap daily, because apparently, some bitrot already set in ... -- Toon Moene, KNMI (Weer/Onderzoek), The Netherlands Phone: +31 30 2206443; e-mail: mo...@knmi.nl
Re: adding an argument for test execution in testsuite
It is unfortunate that UPC program cannot use dg-additional-sources
as we would need to change our run-time to support this option. By the
time we reach main run-time is already initialized to support specified
number of threads. One of the options might be to define a default number
of threads to run if number is not specified.
Anyway, I spent a little bit more time on this and was able to create a
wrapper for upc_load function the same way it is done in gcc-dg.exp
(renaming the old upc_load into prev_upc_load). Wrapper adds the necessary
flags for dynamic environment. Notice that ${tool}_load already accepts
arguments that can be passed to the program.
Nenad
On 5/4/11 3:32 PM, Janis Johnson wrote:
On 05/04/2011 11:21 AM, Nenad Vukicevic wrote:
It seems that I fixed my problem by defining remote_spawn
procedure (and fixing the order of loading libraries :) ) in my
own upc-dg.exp file and adding a line to it that append
additional arguments to the command line: append commandline
$upc_run_arguments.
global $upc_run_arguments is getting set before dg-test is being
called. I used a simple string compare to see if dynamic
threads are required. So far it works as expected.
Working so far shouldn't be good enough, especially if your test will
be run for a variety of targets.
Presumably you don't really need the number of threads to be specified
on the command line, you just need for it to look as if it were
specified at run time. You could, for example, define it in a second
source file included in the test via dg-additional-sources and use it
from a global variable or call a function to get it.
Janis
Re: Why is this a problem in the C++ bootstrap and not the normal one ?
On Thu, May 12, 2011 at 1:32 AM, Toon Moene mo...@knmi.nl wrote: ../../gcc/gcc/objc/objc-next-runtime-abi-02.c: In function 'const char* newabi_append_ro(const char*)': ../../gcc/gcc/objc/objc-next-runtime-abi-02.c:1885:29: error: invalid conversion from 'const char*' to 'char*' [-fpermissive] I have to see if it is useful to keep on testing the C++ bootstrap daily, because apparently, some bitrot already set in ... Yes, I believe it is useful precisely because of these silent regressions. -- Gaby
Re: basic bloc chaining: using dominance
On Wed, May 11, 2011 at 10:03 PM, Ian Lance Taylor i...@google.com wrote: Pierre Vittet pier...@pvittet.com writes: First, thanks for your help. I have looked at several function using calculate_dominance_info(). From what I understand, when you have finish to use it, you have to clear the structure by making a free_dominance_info(). In the function flow_loops_find (file gcc/cfgloop.c), there is a call to calculate_dominance_info() without call to free_dominance_info(). I feel it is a bug, no? Not in this case, no. The caller or a later pass is responsible for freeing it in this case. There should ideally be a comment about this. dominator information should be freed if it is made invalid by CFG transformations. Otherwise the policy is to keep it around to avoid re-computing it (too many passes need it). For post-dominator info the policy is to always free it. Richard. Ian
Re: Non-optimal stack usage with C++ temporaries
On Wed, May 11, 2011 at 10:15 PM, Matt Fischer mattfische...@gmail.com wrote:
I've noticed some behavior with g++ that seems strange to me. I don't
know if there's some technicality in the C++ standard that requires
this, or if it's just a limitation to the optimization code, but it
seemed strange so I thought I'd see if anybody could shed more light
on it.
Here's a test program that illustrates the behavior:
struct Foo {
char buf[256];
Foo() {} // suppress automatically-generated constructor code for clarity
~Foo() {}
};
void func0(const Foo );
void func1(const Foo );
void func2(const Foo );
void func3(const Foo );
void f()
{
func0(Foo());
func1(Foo());
func2(Foo());
func3(Foo());
}
Compiling with -O2 and -fno-stack-protector -fno-exceptions for
clarity, on g++ 4.4.3, gives the following:
f():
0: 55 push %ebp
1: 89 e5 mov %esp,%ebp
3: 81 ec 18 04 00 00 sub $0x418,%esp
9: 8d 85 f8 fb ff ff lea -0x408(%ebp),%eax
f: 89 04 24 mov %eax,(%esp)
12: e8 fc ff ff ff call 13 _Z1fv+0x13
17: 8d 85 f8 fc ff ff lea -0x308(%ebp),%eax
1d: 89 04 24 mov %eax,(%esp)
20: e8 fc ff ff ff call 21 _Z1fv+0x21
25: 8d 85 f8 fd ff ff lea -0x208(%ebp),%eax
2b: 89 04 24 mov %eax,(%esp)
2e: e8 fc ff ff ff call 2f _Z1fv+0x2f
33: 8d 85 f8 fe ff ff lea -0x108(%ebp),%eax
39: 89 04 24 mov %eax,(%esp)
3c: e8 fc ff ff ff call 3d _Z1fv+0x3d
41: c9 leave
42: c3 ret
The function makes four function calls, each of which constructs a
temporary for the parameter. The compiler dutifully allocates stack
space to construct these, but it seems to allocate separate stack
space for each of the temporaries. This seems unnecessary--since
their lifetimes don't overlap, the same stack space could be used for
each of them. The real-life code I adapted this example from had a
fairly large number of temporaries strewn throughout it, each of which
were quite large, so this behavior caused the generated function to
use up a pretty substantial amount of stack, for what seems like no
good reason.
My question is, is this expected behavior? My understanding of the
C++ standard is that each of those temporaries goes away at the
semicolon, so it seems like they have non-overlapping lifetimes, but I
know there are some exceptions to that rule. Could someone comment on
whether this is an actual bug, or required for some reason by the
standard, or just behavior that not enough people have run into
problems with?
It's a missed optimization and not easy to fix.
Richard.
Thanks,
Matt
Can the size of pointers to data and text be different?
I am using gcc4.3.2. In our microcontroller, move instruction(mov reg, imm) can accept 16bits and 32bits immediate operand. The data memory size is less than 64KB, however, code memory size is larger than 64KB. The immediate operand may be addresses of variables in data sections and function pointers. The address of variables can be represented by 16bits. However, function pointers may be larger than 16bits. I'd like to use mov reg, imm16 for addresses of variables and mov reg, imm32 for function pointers. So that the code size can be a little bit smaller. Another way to understand the requirement is the size of pointers to data and text have to be different. How can I select appropriate mov for them? I tried to use LABEL_REF and SYMBOL_REL to distinguish between them, but it didn't help. It seems that function pointers are treated as symbols too. Are there any other cases that references to functions in text sections are used in data sections? Thanks. -Qifei Fan
More atomic functions please
Hello,
I'm not sure if it should be better handled as missed optimization,
but there is a certain lack of functionality in the GCC's __sync_*
function family.
When implementing a reference counting smart pointer, two operations
are of crucial importance:
void __sync_increment(T* p);
bool __sync_decrement_iszero(T* p);
The former only increments the location pointed to by p, the latter decrements
it and returns true if and only if the result was zero.
Both can be implemented in terms of existing __sync functions (and what
can't? -- since there is __sync_bool_compare_and_swap()), e.g.:
void __sync_increment(T* p) {
__sync_fetch_and_add(p, 1);
}
bool __sync_decrement(T* p) {
return __sync_fetch_and_add(p, -1) == 1;
}
Unfortunately, onx86/x64 both are compiled in a rather poor way:
__sync_increment:
lock addl $x01,(ptr)
which is longer than:
lock incl (ptr)
__sync_decrement:
movl -1, %rA
lock xadd %rA, (ptr)
cmpl $0x01, %rA
je/jne...
which is undoubtedly longer than lock dec and wastes a register.
I can optimally implement the increment function with a bit of inline
assembly, but decrement is not so lucky, as there is no way to
inform the compiler the result is in the flags register. One must retreat
to something like that:
lock decl (ptr)
sete %rA
which GCC will finally use to perform a comparison in if(), emitting:
lock decl (ptr)
sete %rA
testb %rA, %rA
je/jne...
which is hardly an improvement. On the other hand, the __sync functions
integrate perfectly with the flag system (i.e. the pairs like cmpxchg/jne),
so implementing the changes in the compiler gives far better opportunities
to emit an optimal sequence compared to what can inline assembly do.
As my code is to a high degree propelled by atomic power, I would like to
ask you to provide these functions or tweak the optimizer in order to notice
the aforementioned idioms.
There is also lack of generic __sync_exchange() -- quite an important operation
in lock-free programming. It could be implemented in terms of compare_exchange,
but many platforms have native support for it and thus it should be
exposed at the
API level, tweaking the optimizer is not the proper way IMHO.
Best regards,
Piotr Wydersk
Re: More atomic functions please
On Thu, 12 May 2011, Piotr Wyderski wrote: Hello, I'm not sure if it should be better handled as missed optimization, but there is a certain lack of functionality in the GCC's __sync_* function family. I don't think we should add new functions to that family; instead the aim should be to implement the functionality (built-in functions etc.) required for a good implementation of the C1x and C++0x atomics support, and recommend users to use those in future. http://gcc.gnu.org/wiki/Atomic -- Joseph S. Myers jos...@codesourcery.com
Re: More atomic functions please
On Thu, May 12, 2011 at 06:11:59PM +0200, Piotr Wyderski wrote:
Hello,
I'm not sure if it should be better handled as missed optimization,
but there is a certain lack of functionality in the GCC's __sync_*
function family.
When implementing a reference counting smart pointer, two operations
are of crucial importance:
void __sync_increment(T* p);
bool __sync_decrement_iszero(T* p);
The former only increments the location pointed to by p, the latter decrements
it and returns true if and only if the result was zero.
Both can be implemented in terms of existing __sync functions (and what
can't? -- since there is __sync_bool_compare_and_swap()), e.g.:
void __sync_increment(T* p) {
__sync_fetch_and_add(p, 1);
}
bool __sync_decrement(T* p) {
return __sync_fetch_and_add(p, -1) == 1;
}
And that's the right thing to do. If the generated code is not optimal, we
should
just improve __sync_fetch_and_add code generation.
It isn't hard to special case addition of 1 or -1, and we already care whether
the result of the builtin is used or ignored. For == 1 we could add some
pattern that
combiner would merge.
Please file an enhancement request in gcc bugzilla.
Jakub
Re: More atomic functions please
On Thu, May 12, 2011 at 06:11:59PM +0200, Piotr Wyderski wrote: Unfortunately, onx86/x64 both are compiled in a rather poor way: __sync_increment: lock addl $x01,(ptr) which is longer than: lock incl (ptr) GCC actually generates lock incl (ptr) already now, it just depends on which CPU you optimize for. /* X86_TUNE_USE_INCDEC */ ~(m_PENT4 | m_NOCONA | m_CORE2I7 | m_GENERIC | m_ATOM), So, if you say -mtune=bdver1 or -mtune=k8, it will generate incl, if addl is better (e.g. on Atom incl is very bad compared to addl $1), it will generate it. Jakub
gcc-4.5-20110512 is now available
Snapshot gcc-4.5-20110512 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20110512/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_5-branch revision 173717 You'll find: gcc-4.5-20110512.tar.bz2 Complete GCC (includes all of below) MD5=12f0c75f2b235dec5b87c4831dc477e3 SHA1=44f24ef585da1a68f2f0d98b87d86830541e7ce3 gcc-core-4.5-20110512.tar.bz2C front end and core compiler MD5=b00358e1c0d93b8ac6228972f5d1ca80 SHA1=3a8248c56490b83ff2f42a818cc647c7cc657ab3 gcc-ada-4.5-20110512.tar.bz2 Ada front end and runtime MD5=f99272c6d21b7ed01f72637c3962d094 SHA1=7b0032e6dc688811ecb89507f3e9f24a6a1498fc gcc-fortran-4.5-20110512.tar.bz2 Fortran front end and runtime MD5=32202cf5257900baaa31eb5da9e6395d SHA1=f29bdb2328e89b34a9de43a156bda42b970f1ebe gcc-g++-4.5-20110512.tar.bz2 C++ front end and runtime MD5=6623d74e88a7b1e4f742106a997087c5 SHA1=9c450b0ea6ba2134f5c80e4df733c6d83d101501 gcc-go-4.5-20110512.tar.bz2 Go front end and runtime MD5=5912c4cc9d1966ee57132f15cda52dd5 SHA1=28f46ef6e0eeada39f9bca31099bd8164b06fe95 gcc-java-4.5-20110512.tar.bz2Java front end and runtime MD5=469a0097d034dcafd5fb13fefc665708 SHA1=778ee54103c6c30c6f925600628ed1626f7e9928 gcc-objc-4.5-20110512.tar.bz2Objective-C front end and runtime MD5=e20978097265a3d04bdfd3b0e95de0a7 SHA1=765a2128abe8ec13a9201e1bc2c319ee0361930a gcc-testsuite-4.5-20110512.tar.bz2 The GCC testsuite MD5=34f99bfac27722938399d18462aa591b SHA1=ba9f9ad674a7e40c597f11fbf0cb8db10f860b38 Diffs from 4.5-20110505 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.5 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Can the size of pointers to data and text be different?
fanqifei fanqi...@gmail.com writes: I am using gcc4.3.2. In our microcontroller, move instruction(mov reg, imm) can accept 16bits and 32bits immediate operand. The data memory size is less than 64KB, however, code memory size is larger than 64KB. The immediate operand may be addresses of variables in data sections and function pointers. The address of variables can be represented by 16bits. However, function pointers may be larger than 16bits. I'd like to use mov reg, imm16 for addresses of variables and mov reg, imm32 for function pointers. So that the code size can be a little bit smaller. Another way to understand the requirement is the size of pointers to data and text have to be different. How can I select appropriate mov for them? I tried to use LABEL_REF and SYMBOL_REL to distinguish between them, but it didn't help. It seems that function pointers are treated as symbols too. Are there any other cases that references to functions in text sections are used in data sections? SYMBOL_REF_FUNCTION_P. (A LABEL_REF refers to a goto label.) Ian
Re: More atomic functions please
Jakub Jelinek wrote: /* X86_TUNE_USE_INCDEC */ ~(m_PENT4 | m_NOCONA | m_CORE2I7 | m_GENERIC | m_ATOM), So, if you say -mtune=bdver1 or -mtune=k8, it will generate incl, if addl is better (e.g. on Atom incl is very bad compared to addl $1), it will generate it. Why is lock inc/dec worse than add/sub on Core2I7? The only difference I know of is the way the carry flag is handled. Best regards, Piotr Wyderski
[Bug fortran/48972] OPEN with Unicode file name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48972
--- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2011-05-12
06:15:57 UTC ---
For the diagnostic, the following untested patch should do. For Unicode
file-name support more work needs to be done ...
--- a/gcc/fortran/io.c
+++ b/gcc/fortran/io.c
@@ -1478,6 +1478,13 @@ resolve_tag (const io_tag *tag, gfc_expr *e)
return FAILURE;
}
+ if (e-ts.type == BT_CHARACTER e-ts.kind != gfc_default_character_kind)
+{
+ gfc_error (%s tag at %L must be a character string of default kind,
+tag-name, e-where);
+ return FAILURE;
+}
+
if (e-rank != 0)
{
gfc_error (%s tag at %L must be scalar, tag-name, e-where);
[Bug rtl-optimization/48971] [4.7 regression] ICE with -msoft-float -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48971 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Target||sparc-*-* Status|UNCONFIRMED |NEW Keywords||ice-on-valid-code Last reconfirmed||2011.05.12 06:56:03 Component|bootstrap |rtl-optimization CC||ebotcazou at gcc dot ||gnu.org Ever Confirmed|0 |1 Summary|sparc-rtems does not build |[4.7 regression] ICE with ||-msoft-float -O2 Severity|critical|normal --- Comment #1 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-05-12 06:56:03 UTC --- This is -msoft-float though. Again recent IRA changes I'm afraid...
[Bug target/48941] [arm gcc] NEON: Stack pointer operations performed even tho stack is not accessed at all in function.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48941
Ramana Radhakrishnan ramana at gcc dot gnu.org changed:
What|Removed |Added
Target|arm-elf |arm-elf, arm-eabi
Status|UNCONFIRMED |NEW
Last reconfirmed||2011.05.12 07:07:51
CC||ramana at gcc dot gnu.org
Ever Confirmed|0 |1
--- Comment #1 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2011-05-12
07:07:51 UTC ---
Occurs with trunk as well.
This is what I see with GCC: (GNU) 4.7.0 20110413 (experimental) [trunk
revision 172363
strfp, [sp, #-4]!
addfp, sp, #0
subsp, sp, #20
vldmiar0, {d20-d21}
vmovq11, q10 @ v4sf
subsp, sp, #48
addr3, sp, #15
bicr3, r3, #15
vzip.32q10, q11
vstrd22, [r3, #16]
vstrd23, [r3, #24]
vstmiar3, {d20-d21}
vldmiar1, {d18-d19}
vmovq8, q9 @ v4sf
vmovd24, d21
vzip.32q9, q8
vstrd16, [r3, #16]
vstrd17, [r3, #24]
vstmiar3, {d18-d19}
vmovd26, d22
vmovd25, d16
vmovd23, d18
vmul.f32d16, d24, d25
vmul.f32d22, d26, d23
vmovd18, d19
vmul.f32d17, d20, d18
vmls.f32d16, d26, d18
vmls.f32d22, d20, d25
vmls.f32d17, d24, d23
vuzp.32d16, d22
vmovd18, d16
vmovd19, d17
vmovr0, r1, d18 @ v4sf
vmovr2, r3, d19
addsp, fp, #0
ldmfdsp!, {fp}
bxlr
[Bug tree-optimization/48973] [4.3/4.4/4.5/4.6/4.7 Regression] Inliner bug with one-bit (1-bit) bitfield
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48973
--- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-12
07:20:30 UTC ---
extern void abort (void);
struct S { int f : 1; } s;
int v = -1;
void
foo (void)
{
s.f = (v 1) 0;
}
void
bar (unsigned int x)
{
if (x != -1U)
abort ();
}
int
main ()
{
foo ();
bar (s.f);
return 0;
}
[Bug target/48941] [arm gcc] NEON: Stack pointer operations performed even tho stack is not accessed at all in function.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48941 rsand...@gcc.gnu.org rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||rsandifo at gcc dot gnu.org AssignedTo|unassigned at gcc dot |rsandifo at gcc dot gnu.org |gnu.org | --- Comment #2 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org 2011-05-12 07:18:13 UTC --- The problem seems to be that arm_neon.h implementation of vzip* is returning the result by reference rather than by value.
[Bug tree-optimization/48973] [4.3/4.4/4.5/4.6/4.7 Regression] Inliner bug with one-bit (1-bit) bitfield
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48973
--- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-12
07:29:37 UTC ---
extern void abort (void);
struct S { int f : 1; } s;
int v = -1;
void
foo (unsigned int x)
{
if (x != -1U)
abort ();
}
int
main ()
{
s.f = (v 1) 0;
foo (s.f);
return 0;
}
Smaller testcase which failed already in 4.2, apparently introduced in between
r97500 and r98750.
[Bug tree-optimization/48973] [4.3/4.4/4.5/4.6/4.7 Regression] Inliner bug with one-bit (1-bit) bitfield
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48973
--- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-12
07:36:07 UTC ---
And even more reduced:
extern void abort (void);
struct S { int f : 1; } s;
int v = -1;
int
main ()
{
s.f = (v 1) 0;
if ((unsigned int) s.f != -1U)
abort ();
return 0;
}
[Bug tree-optimization/48975] New: ICE in execute_cse_reciprocals() with -fno-tree-slp-vectorize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48975
Summary: ICE in execute_cse_reciprocals() with
-fno-tree-slp-vectorize
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: arthur.j.odw...@gmail.com
Created attachment 24232
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24232
Output of ajo-gcc -w -O1 -finline-functions -ftree-vectorize -ffast-math
-fno-tree-slp-vectorize -c test1281247203.c
This reproduces for me with svn revision 173589 (2011-05-09). It doesn't
reproduce with gcc 4.5.1. I'm on Ubuntu 10.10, x86-64.
cat test1281247203.c EOF
static int ADD(int x) {
return (x 0) ? 0 : x+1;
}
void func_65(unsigned int x) {
int l_376 = -1;
lbl_469:
while (x) {
x = ADD(x);
}
}
EOF
gcc -w -O1 -finline-functions -ftree-vectorize -ffast-math
-fno-tree-slp-vectorize -c test1281247203.c
test1281247203.c: In function ‘func_65’:
test1281247203.c:5:6: internal compiler error: in execute_cse_reciprocals, at
tree-ssa-math-opts.c:512
This test case is reduced from the output of Csmith 2.1.0 (git hash 541a6480,
https://github.com/csmith-project/csmith/), using the following command line:
csmith --no-paranoid --longlong --no-pointers --arrays --jumps --consts
--no-volatiles --no-checksum --no-divs --no-muls --no-bitfields
--no-packed-struct -s 1281247203
[Bug target/48743] -march=native mis-detects AMD K6-2+ / K6-3 as Athlon - compiled C fails with illegal instruction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48743 --- Comment #3 from Zuxy zuxy.meng at gmail dot com 2011-05-12 08:27:56 UTC --- Created attachment 24233 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24233 Proposed patch For a brief time AMD produced K6-2+ and K6-3+ processors, targeting mobile market. These processors support Extended 3DNow! but not CMOV or Extended MMX (a subset of SSE) and are detected as Athlon by GCC so GCC will generate CMOV for them, leading to #UD. The patch solves the problem by differentiating K6 and Athlon by Extended MMX rather than Extended 3DNow!.
[Bug tree-optimization/48973] [4.3/4.4/4.5/4.6/4.7 Regression] Inliner bug with one-bit (1-bit) bitfield
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48973 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.05.12 07:19:50 CC||jakub at gcc dot gnu.org Known to work||4.2.3 Target Milestone|--- |4.3.6 Summary|Inliner bug with one-bit|[4.3/4.4/4.5/4.6/4.7 |(1-bit) bitfield|Regression] Inliner bug ||with one-bit (1-bit) ||bitfield Ever Confirmed|0 |1 Known to fail||4.3.3, 4.6.0, 4.7.0 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-12 07:19:50 UTC --- Confirmed, started in between r11 and r112000, but strangely works in 4.2 which has branched off in r117923. Looking into it.
[Bug target/48941] [arm gcc] NEON: Stack pointer operations performed even tho stack is not accessed at all in function.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48941 --- Comment #3 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org 2011-05-12 08:46:54 UTC --- Created attachment 24234 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24234 Proposed patch The attached patch seems to fix the testcase and doesn't regress neon.exp. I'll test it fully next week. We still generate more moves than necessary, but that's a separate problem.
[Bug tree-optimization/48973] [4.3/4.4/4.5/4.6/4.7 Regression] Inliner bug with one-bit (1-bit) bitfield
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48973
--- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-12
08:29:09 UTC ---
Even smaller:
extern void abort (void);
struct S { int f : 1; } s;
int v = -1;
int
main ()
{
s.f = v 0;
if ((unsigned int) s.f != -1U)
abort ();
return 0;
}
I'd say the bug is during expansion of a comparison with signed 1 bit type.
Then the comparison needs to result 0 / -1 instead of 0 / 1. I think it would
be difficult to adjust all the conditional expansion to handle this very rare
special case, so probably it will be better to expand such conditionals as
if it was unsigned:1 or unsigned char typed comparison, followed by cast from
that type to signed:1.
[Bug lto/48947] 4.6.0 fails to link ffmpeg with LTO and gold
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48947 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added CC||iant at google dot com --- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2011-05-12 08:51:25 UTC --- (In reply to comment #4) I checked those errors with both binutils 2.21 release and 2.22 CVS (10th of May). gcc -### Using built-in specs. COLLECT_GCC=/???/x86_64-gcc-4.6.0/bin/gcc COLLECT_LTO_WRAPPER=/???/x86_64-gcc-4.6.0/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../configure --prefix=/???/x86_64-gcc-4.6.0 --enable-shared --with-arch=native --enable-languages=c,c++ --enable-lto --enable-plugin --enable-gold --enable-linker-build-id --disable-multilib --enable-ld=default --with-plugin-ld=ld.gold Thread model: posix gcc version 4.6.0 (GCC) If you mean CC=gcc -flto -fuse-linker-plugin, I get the same errors. With using GNU ld I mean configuring with --with-plugin-ld=ld.bfd (or omitting that configure option). I'm CCing a gold expert, maybe he can shed some light on that error. I suppose all object files _are_ built with -fPIC (eventually LTO takes some symbols local by making them have hidden visibility - can that cause issues?).
[Bug c++/48969] ICE with -std=c++0x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48969 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-05-12 08:56:57 UTC --- it looks like tsubst recurses until it runs out of stack clang also segfaults with -std=c++0x, and not without
[Bug tree-optimization/48975] [4.6/4.7 Regression] ICE in execute_cse_reciprocals() with -fno-tree-slp-vectorize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48975 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Keywords||ice-checking Last reconfirmed||2011.05.12 09:14:00 CC||jakub at gcc dot gnu.org AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 Summary|ICE in |[4.6/4.7 Regression] ICE in |execute_cse_reciprocals() |execute_cse_reciprocals() |with|with |-fno-tree-slp-vectorize |-fno-tree-slp-vectorize Target Milestone|--- |4.6.1 Known to fail||4.6.0, 4.7.0 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-12 09:14:00 UTC --- Confirmed, started in between r160500 and r161170, ICEs even on 4.6 branch if --enable-checking.
[Bug middle-end/48973] [4.3/4.4/4.5/4.6/4.7 Regression] Inliner bug with one-bit (1-bit) bitfield
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48973 --- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2011-05-12 09:00:59 UTC --- Fixed with bitfield lowering where we expand from v.0_1 = v; BF.1_3 = MEM[(struct S *)s]; D.2700_4 = BF.1_3 -2; D.2702_6 = v.0_1 0; BF.1_7 = D.2702_6 | D.2700_4; MEM[(struct S *)s] = BF.1_7; D.2693_9 = (unnamed-signed:1) BF.1_7; D.2694_10 = (unsigned int) D.2693_9; if (D.2694_10 != 4294967295) similar to what Jakub proposed to do manually.
[Bug c/48968] incorrect warning about longjmp/vfork clobbering a local (-W -O2, x86-64)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48968 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-05-12 09:11:45 UTC --- Well, XXXevent is scalarized by SRA (-fno-tree-sra gets rid of the error) and I suppose nothing prevents that register to be propagated to other indirect uses. So it might be indeed live over the setjmp call.
[Bug tree-optimization/48975] [4.6/4.7 Regression] ICE in execute_cse_reciprocals() with -fno-tree-slp-vectorize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48975 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-12 09:25:46 UTC --- tree-if-conv.c fails to free_bb_predicate on some bbs, thus bb-aux is non-NULL on entry to following passes.
[Bug middle-end/48973] [4.3/4.4/4.5/4.6/4.7 Regression] Inliner bug with one-bit (1-bit) bitfield
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48973 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-12 09:04:30 UTC --- Created attachment 24235 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24235 gcc46-pr48973.patch Untested fix.
[Bug tree-optimization/48172] [4.5/4.6/4.7 Regression] incorrect vectorization of loop in GCC 4.5.* with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48172 --- Comment #8 from Richard Guenther rguenth at gcc dot gnu.org 2011-05-12 10:40:02 UTC --- Created attachment 24236 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24236 patch Patch I'm going to test.
[Bug middle-end/48973] [4.3/4.4/4.5/4.6/4.7 Regression] Inliner bug with one-bit (1-bit) bitfield
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48973 --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-12 10:31:42 UTC --- (In reply to comment #6) Fixed with bitfield lowering where we expand from v.0_1 = v; BF.1_3 = MEM[(struct S *)s]; D.2700_4 = BF.1_3 -2; D.2702_6 = v.0_1 0; BF.1_7 = D.2702_6 | D.2700_4; MEM[(struct S *)s] = BF.1_7; D.2693_9 = (unnamed-signed:1) BF.1_7; D.2694_10 = (unsigned int) D.2693_9; if (D.2694_10 != 4294967295) similar to what Jakub proposed to do manually. Well, if bitfield lowering does this and nothing cleans it up, there is room for improvement. It would be sad if it couldn't be optimized already at the tree level back to: v.0_1 = v; BF.1_3 = MEM[(struct S *)s]; D.2700_4 = BF.1_3 -2; D.2702_6 = v.0_1 0; BF.1_7 = D.2702_6 | D.2700_4; MEM[(struct S *)s] = BF.1_7; D.2693_9 = (unnamed-signed:1) D.2702_6; // change here. Assuming D.2702 // is either 1 precision, or // unsigned D.2694_10 = (unsigned int) D.2693_9; if (D.2694_10 != 4294967295)
[Bug fortran/45823] Bogus warning for intrinsic module procedures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45823
--- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2011-05-12
10:35:23 UTC ---
(In reply to comment #1)
This bug basically makes the option -Wsurprising useless in combination with
iso_fortran_env.
Well, you can still use ONLY - which is a decent work around, unless you really
need the two functions.
Regarding the test case from comment 0: resolve_intrinsic is called twice -
once from resolve_symbol (which sets then ts.type) and then again for
resolve_function; the second call to resolve_intrinsic generates then the
warning.
The following patch should work. It prevents the warning but if one tries to
modify the type, one gets the normal module warning:
Error: Symbol 'compiler_options' at (1) already has basic type of CHARACTER
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -1454,7 +1454,7 @@ resolve_intrinsic (gfc_symbol *sym, locus *loc)
if (isym)
{
if (sym-ts.type != BT_UNKNOWN gfc_option.warn_surprising
- !sym-attr.implicit_type)
+ !sym-attr.implicit_type !sym-from_intmod)
gfc_warning (Type specified for intrinsic function '%s' at %L is
ignored, sym-name, sym-declared_at);
[Bug tree-optimization/48975] [4.6/4.7 Regression] ICE in execute_cse_reciprocals() with -fno-tree-slp-vectorize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48975 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-12 11:09:36 UTC --- Created attachment 24237 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24237 gcc46-pr48975.patch The problem was that combine_blocks removes most of the bbs in the loop, keeps around only header, latch and maybe exit_bb, but free_bb_predicate is called in the caller on ifc_bbs entries starting with 0 (loop-header which stays, fine) up to number of remaining bbs in the loop - 1 (that number can be at most 3). But nothing reordered ifc_bbs entries, so it very well can free_bb_predicate of a removed bb (use after free) and can fail to free_bb_predicate for latch or exit_bb. This patch fixes it by free_bb_predicate for all bbs in the loop already before (some of) the bbs are removed and ensures the caller doesn't try to do that again.
[Bug lto/48952] ICE in inline_merge_summary during linux kernel LTO build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48952 --- Comment #3 from Jan Hubicka hubicka at gcc dot gnu.org 2011-05-12 11:30:48 UTC --- Author: hubicka Date: Thu May 12 11:30:42 2011 New Revision: 173700 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=173700 Log: PR lto/48952 * lto.c (do_whole_program_analysis): Do not register cgraph hooks. Modified: trunk/gcc/lto/ChangeLog trunk/gcc/lto/lto.c
[Bug tree-optimization/48702] [4.6/4.7 Regression] optimization regression with gcc-4.6 on x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48702 --- Comment #13 from Richard Guenther rguenth at gcc dot gnu.org 2011-05-12 10:52:54 UTC --- (In reply to comment #12) (In reply to comment #3) I have a patch that makes it fail on trunk as well. IVOPTs generates for (p = a; p != a - 3; --p) *(p + 3) = ... and alias analysis doesn't like this invalid pointer. I wonder why ivopt does not select the iv candidate whose base is a+3. I think that one is not in the list of initial candidates. I think for that sake we would want to add stripped base + object size (+ 1?) (if we know it) as IV candidate iff iv-step is negative, iff iv-step is positive continue to add base. I don't like the alias oracle fixups too much, but I guess we have to benchmark both alternatives.
[Bug middle-end/48973] [4.3/4.4/4.5/4.6/4.7 Regression] Inliner bug with one-bit (1-bit) bitfield
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48973 --- Comment #9 from Richard Guenther rguenth at gcc dot gnu.org 2011-05-12 11:36:21 UTC --- (In reply to comment #8) (In reply to comment #6) Fixed with bitfield lowering where we expand from v.0_1 = v; BF.1_3 = MEM[(struct S *)s]; D.2700_4 = BF.1_3 -2; D.2702_6 = v.0_1 0; BF.1_7 = D.2702_6 | D.2700_4; MEM[(struct S *)s] = BF.1_7; D.2693_9 = (unnamed-signed:1) BF.1_7; D.2694_10 = (unsigned int) D.2693_9; if (D.2694_10 != 4294967295) similar to what Jakub proposed to do manually. Well, if bitfield lowering does this and nothing cleans it up, there is room for improvement. It would be sad if it couldn't be optimized already at the tree level back to: v.0_1 = v; BF.1_3 = MEM[(struct S *)s]; D.2700_4 = BF.1_3 -2; D.2702_6 = v.0_1 0; BF.1_7 = D.2702_6 | D.2700_4; MEM[(struct S *)s] = BF.1_7; D.2693_9 = (unnamed-signed:1) D.2702_6; // change here. Assuming D.2702 // is either 1 precision, or // unsigned D.2694_10 = (unsigned int) D.2693_9; if (D.2694_10 != 4294967295) Yeah, we can combine that with the comparison - but I'm not sure we want to have compares with 1-bit precision quantities, do we? Or we want to optimize this to tem = D.2702_6 CST; if (tem != 0) instead?
[Bug tree-optimization/48172] [4.5/4.6/4.7 Regression] incorrect vectorization of loop in GCC 4.5.* with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48172 --- Comment #9 from Ira Rosen irar at il dot ibm.com 2011-05-12 11:48:56 UTC --- (In reply to comment #8) Created attachment 24236 [details] patch Patch I'm going to test. So, segment_length = scalar_step * vf * scalar_niters? I think we don't need vf here. Also, why not do that only for different steps? Thanks, Ira
[Bug debug/48967] [4.6/4.7 Regression] ICE during use_narrower_mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48967 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-12 11:59:34 UTC --- Author: jakub Date: Thu May 12 11:59:32 2011 New Revision: 173702 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=173702 Log: PR debug/48967 * var-tracking.c (use_narrower_mode_test) case REG: Return 1 if validate_subreg fails. * g++.dg/opt/pr48967.C: New test. Added: branches/gcc-4_6-branch/gcc/testsuite/g++.dg/opt/pr48967.C Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/testsuite/ChangeLog branches/gcc-4_6-branch/gcc/var-tracking.c
[Bug fortran/45823] Bogus warning for intrinsic module procedures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45823 Thomas Henlich thenlich at users dot sourceforge.net changed: What|Removed |Added CC||thenlich at users dot ||sourceforge.net --- Comment #1 from Thomas Henlich thenlich at users dot sourceforge.net 2011-05-12 09:40:37 UTC --- Here is another example. The warning appears even if there are no calls to to compiler_options() or compiler_version(). This bug basically makes the option -Wsurprising useless in combination with iso_fortran_env. test_mod.f90: module test_mod use iso_fortran_env end module test_mod test.f90: use test_mod end gcc -c test_mod.f90 gfortran -c -Wsurprising test.f90 test.f90:1.12: use test_mod 1 Warning: Type specified for intrinsic function 'compiler_options' at (1) is ignored test.f90:1.12: use test_mod 1 Warning: Type specified for intrinsic function 'compiler_version' at (1) is ignored
[Bug fortran/48976] New: INQUIRE with STREAM= not supported
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48976 Summary: INQUIRE with STREAM= not supported Product: gcc Version: 4.7.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org CC: jvdeli...@gcc.gnu.org Fortran 2003/2008 support INQUIRE for STREAM: 9.10.2.31 STREAM= specifier in the INQUIRE statement The scalar-default-char-variable in the STREAM= specifier is assigned the value YES if STREAM is included in the set of allowed access methods for the file, NO if STREAM is not included in the set of allowed access methods for the file, and UNKNOWN if the processor is unable to determine whether STREAM is included in the set of allowed access methods for the file or if the unit identified by file-unit-number is not connected to a file. However, gfortran rejects it with: INQUIRE(99, stream=str) 1 Error: Syntax error in INQUIRE statement at (1) character(len=20) :: str INQUIRE(99, stream=str) end
[Bug debug/48967] [4.6/4.7 Regression] ICE during use_narrower_mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48967 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-12 11:54:36 UTC --- Author: jakub Date: Thu May 12 11:54:33 2011 New Revision: 173701 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=173701 Log: PR debug/48967 * var-tracking.c (use_narrower_mode_test) case REG: Return 1 if validate_subreg fails. * g++.dg/opt/pr48967.C: New test. Added: trunk/gcc/testsuite/g++.dg/opt/pr48967.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/var-tracking.c
[Bug fortran/48972] OPEN with Unicode file name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48972 --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2011-05-12 12:39:32 UTC --- Created attachment 24238 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24238 Test case (In reply to comment #1) For the diagnostic, the following untested patch should do. Well, almost. It fails for FORMAT/fmt=; I have to admit that I do not quite understand why only for e-expr_type == EXPR_CONSTANT a default-kind character is tested for in io.c's resolve_tag_format. Jerry, could you have a look? I am a bit lost.
[Bug tree-optimization/48172] [4.5/4.6/4.7 Regression] incorrect vectorization of loop in GCC 4.5.* with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48172 --- Comment #10 from Richard Guenther rguenth at gcc dot gnu.org 2011-05-12 12:14:48 UTC --- Author: rguenth Date: Thu May 12 12:14:45 2011 New Revision: 173703 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=173703 Log: 2011-05-12 Richard Guenther rguent...@suse.de PR tree-optimization/48172 * tree-vect-loop-manip.c (vect_vfa_segment_size): Do not exclude the number of iterations from the segment size calculation. (vect_create_cond_for_alias_checks): Adjust. * gcc.dg/vect/pr48172.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/vect/pr48172.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-loop-manip.c
[Bug c/48968] incorrect warning about longjmp/vfork clobbering a local (-W -O2, x86-64)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48968 --- Comment #3 from Andreas Schwab sch...@linux-m68k.org 2011-05-12 11:00:16 UTC --- That function doesn't actually call setjmp.
[Bug tree-optimization/48172] [4.5/4.6/4.7 Regression] incorrect vectorization of loop in GCC 4.5.* with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48172
--- Comment #12 from Richard Guenther rguenth at gcc dot gnu.org 2011-05-12
12:46:10 UTC ---
Like this?
Index: gcc/tree-vect-loop-manip.c
===
--- gcc/tree-vect-loop-manip.c (revision 173703)
+++ gcc/tree-vect-loop-manip.c (working copy)
@@ -2353,23 +2353,19 @@ vect_create_cond_for_align_checks (loop_
Input:
DR: The data reference.
- VECT_FACTOR: vectorization factor.
- SCALAR_LOOP_NITERS: number of iterations.
+ LENGTH_FACTOR: segment length to consider.
Return an expression whose value is the size of segment which will be
accessed by DR. */
static tree
-vect_vfa_segment_size (struct data_reference *dr, int vect_factor,
+vect_vfa_segment_size (struct data_reference *dr, tree length_factor,
tree scalar_loop_niters)
{
tree segment_length;
segment_length = size_binop (MULT_EXPR,
fold_convert (sizetype, DR_STEP (dr)),
- size_int (vect_factor));
- segment_length = size_binop (MULT_EXPR,
- segment_length,
- fold_convert (sizetype, scalar_loop_niters));
+ fold_convert (sizetype, length_factor));
if (vect_supportable_dr_alignment (dr, false)
== dr_explicit_realign_optimized)
{
@@ -2465,10 +2461,12 @@ vect_create_cond_for_alias_checks (loop_
vect_create_addr_base_for_vector_ref (stmt_b, cond_expr_stmt_list,
NULL_TREE, loop);
- segment_length_a = vect_vfa_segment_size (dr_a, vect_factor,
- scalar_loop_iters);
- segment_length_b = vect_vfa_segment_size (dr_b, vect_factor,
- scalar_loop_iters);
+ if (!operand_equal_p (DR_STEP (dr_a), DR_STEP (dr_b), 0))
+ length_factor = scalar_loop_iters;
+ else
+ length_factor = size_int (vect_factor);
+ segment_length_a = vect_vfa_segment_size (dr_a, length_factor);
+ segment_length_b = vect_vfa_segment_size (dr_b, length_factor);
if (vect_print_dump_info (REPORT_DR_DETAILS))
{
I also think that the re-alignment adjustment needs to be multiplied
by DR_STEP (maybe we only support it for DR_STEP == 1 at the moment).
[Bug tree-optimization/48172] [4.5/4.6/4.7 Regression] incorrect vectorization of loop in GCC 4.5.* with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48172 --- Comment #11 from Richard Guenther rguenth at gcc dot gnu.org 2011-05-12 12:38:15 UTC --- (In reply to comment #9) (In reply to comment #8) Created attachment 24236 [details] patch Patch I'm going to test. So, segment_length = scalar_step * vf * scalar_niters? I think we don't need vf here. Hm, right. I'll prepare a followup. Also, why not do that only for different steps? We don't know this at this point. Maybe we can change the structure of the code somewhat. I'll have a look. Thanks, Ira
[Bug tree-optimization/48172] [4.5/4.6/4.7 Regression] incorrect vectorization of loop in GCC 4.5.* with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48172 --- Comment #13 from Ira Rosen irar at il dot ibm.com 2011-05-12 13:02:39 UTC --- (In reply to comment #12) Like this? Yes, looks good to me. I also think that the re-alignment adjustment needs to be multiplied by DR_STEP (maybe we only support it for DR_STEP == 1 at the moment). The realignment adjustment is for the case when we load two consecutive aligned vectors and extract the relevant elements from them (in Altivec): for a[1:4] we load a[0:3] and a[4:7]. So, the adjustment adds one more vector size to cover that additional loaded vector. I don't see why it needs to be multiplied by DR_STEP. Thanks, Ira
[Bug fortran/48972] OPEN with Unicode file name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48972 Janne Blomqvist jb at gcc dot gnu.org changed: What|Removed |Added CC||jb at gcc dot gnu.org --- Comment #3 from Janne Blomqvist jb at gcc dot gnu.org 2011-05-12 12:56:07 UTC --- Wouldn't a standard-conforming way to support Unicode file names be for gfortran to - Specify that the default character set is UTF-8. - Then an internal read or write could be used to do a UTF-8 - UTF-32 conversion, if the user program uses kind=4 characters. Or if the user program stuffs utf-8 data into default character variables, nothing needs to be done. - When passing a filename in the open statement, on posix this can be passed as-is to open(), on mingw the library would need to do a utf-8 - utf-16 conversion, then call wopen(). And similarly for other syscalls where we pass path names (e.g. stat(), access() and so on). In any case, initially something like your patch in #c1 looks good; regardless of how/if we decide to support Unicode filenames, currently we don't do anything sensible for kind=4 file names. And as you say, it's a standard violation. Similarly to specifying the default character set as UTF-8, we could specify the default encoding as UTF-8 (see ENCODING= in OPEN (9.5.6.9) and INQUIRE (9.10.2.10)). That way we wouldn't need to handle the non-Unicode cases in 10.7.1 at all. I think we're mostly there already, really, what's lacking is perhaps a GFortran and Unicode chapter in the manual.
[Bug fortran/48972] OPEN with Unicode file name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48972 --- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org 2011-05-12 13:37:34 UTC --- (In reply to comment #3) Wouldn't a standard-conforming way to support Unicode file names be for gfortran to I am admittedly a bit lost. - Specify that the default character set is UTF-8. What do you mean by that? I know 1 byte and 4 byte character variables, but I do not see where UTF-8 fits in there. (One can place UTF-8 into character(kind=1) - and it also kind of works OK. But if one wants to use len(), string manipulation (change 3 character to ...), or tabulated I/O that will fail. But as quirky workaround, one can use UTF-8 file names with kind=1 character variables - at least under Unix/Linux.) Regarding the ENCODING= specifier: That's already used for the encoding of the file content - one shan't use it to also modify the interpretation of the FILE string. I still think that the default character encoding should remain 1 byte (kind=1), which is simply passed as is to open(). And UCS-4 as FILE= argument should simply be supported as vendor extension. One just needs to tell the library that the string is in UCS-4. This wide string could then directly used for Windows' _wopen or converted to UTF-8 for Unix/Linux. (The conversion routine exists for UCS-4 - UTF-8 I/O.)
[Bug fortran/48977] New: -fpe-trap=denormal on x86 GLIBC systems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48977 Summary: -fpe-trap=denormal on x86 GLIBC systems Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org Kind of follow up to PR 38810 - and motivated by http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/894fb77cabc6e8c7 GLIBC (and POSIX) do not support FE_DENORMAL and thus -fpe-trap=denormal does not work. However, gfortran has a target version for denormal trapping: fpu-387.h has: if (options.fpe GFC_FPE_DENORMAL) cw = ~_FPU_MASK_DM; [...] if (has_sse()) [...] if (options.fpe GFC_FPE_DENORMAL) cw_sse = ~(_FPU_MASK_DM 7); Expected: If FE_DENORMAL is not supported and target == fpu-387.h, the latter is used. (It could also be of interest for the IEEE modules.)
[Bug tree-optimization/48822] [4.5 Regression] G++ gets stucks and never finishes compilation when enabling -O2/3 optimization options.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48822 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Known to work||4.6.1 Summary|[4.5/4.6 Regression] G++|[4.5 Regression] G++ gets |gets stucks and never |stucks and never finishes |finishes compilation when |compilation when enabling |enabling -O2/3 optimization |-O2/3 optimization options. |options.| --- Comment #9 from Richard Guenther rguenth at gcc dot gnu.org 2011-05-12 14:08:22 UTC --- .
[Bug lto/48978] New: excessive hash table allocation for large lto build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48978 Summary: excessive hash table allocation for large lto build Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: andi-...@firstfloor.org I tried a large LTO build with gcc version 4.7.0 20110511 (experimental) (GCC) on a 18GB machine. It ended with lto1: out of memory allocating 8589934312 bytes after a total of 6827421696 bytes Since a 7+GB single malloc seems somewhat excessive I put a break point on xmalloc_failed. It looks like the hash tables are growing too aggressively? #0 xmalloc_failed (size=8589934312) at ../../gcc/libiberty/xmalloc.c:118 #1 0x00b1b8a8 in xcalloc (nelem=1073741789, elsize=8) at ../../gcc/libiberty/xmalloc.c:164 #2 0x00b16696 in htab_expand (htab=0x11949c0) at ../../gcc/libiberty/hashtab.c:558 #3 0x00b16faa in htab_find_slot_with_hash (htab=0x11949c0, element=0x7fff64c7d0c0, hash=2685589897, insert=INSERT) at ../../gcc/libiberty/hashtab.c:653 #4 0x005a9701 in lookup_type_pair (ob_p=0x1022380, visited_p=0x1022370, t1=value optimized out, t2=value optimized out) at ../../gcc/gcc/gimple.c:3284 #5 0x005b1235 in gtc_visit (sccstate_obstack=Unhandled dwarf expression opcode 0xf3 ) at ../../gcc/gcc/gimple.c:3557 #6 gtc_visit (sccstate_obstack=Unhandled dwarf expression opcode 0xf3 ) at ../../gcc/gcc/gimple.c:3473 #7 0x005b0d69 in gimple_types_compatible_p_1 (t1=0x2aff61dc3b28, t2=0x2affd032b150, p=0x197c33a70, sccstack=0x7fff64c7d188, sccstate=0x9817ee40, sccstate_obstack=0x7fff64c7d190) at ../../gcc/gcc/gimple.c:3717 #8 0x005af31e in gimple_types_compatible_p (t2=0x2affd032b150, t1=0x2aff61dc3b28) at ../../gcc/gcc/gimple.c:3987 #9 gimple_type_eq (t2=0x2affd032b150, t1=0x2aff61dc3b28) at ../../gcc/gcc/gimple.c: #10 0x00b16f1e in htab_find_slot_with_hash (htab=0x2aff56172a10, element=0x2affd032b150, hash=Unhandled dwarf expression opcode 0xf3 ) at ../../gcc/libiberty/hashtab.c:687 #11 0x005af4cd in gimple_register_type (t=0x2affd032b150) at ../../gcc/gcc/gimple.c:4480 #12 0x0049c670 in lto_ft_common (t=0x2affd032aab0) at ../../gcc/gcc/lto/lto.c:296 #13 0x0049c6b9 in lto_ft_decl_minimal (t=0x2affd032aab0) at ../../gcc/gcc/lto/lto.c:309 #14 lto_ft_decl_common (t=0x2affd032aab0) at ../../gcc/gcc/lto/lto.c:319 ---Type return to continue, or q return to quit--- #15 0x0049d25d in lto_ft_field_decl (t=0x2affd032aab0) at ../../gcc/gcc/lto/lto.c:364 #16 lto_fixup_types (t=0x2affd032aab0) at ../../gcc/gcc/lto/lto.c:542 #17 0x0049ddd0 in uniquify_nodes (from=671, data_in=value optimized out) at ../../gcc/gcc/lto/lto.c:618 #18 lto_read_decls (from=671, data_in=value optimized out) at ../../gcc/gcc/lto/lto.c:697 #19 lto_file_finalize (from=671, data_in=value optimized out) at ../../gcc/gcc/lto/lto.c:921 #20 lto_create_files_from_ids (from=671, data_in=value optimized out) at ../../gcc/gcc/lto/lto.c:939 #21 0x00b1b6cf in splay_tree_foreach_helper (data=0x7fff64c7d520, fn=0x49dca0 lto_create_files_from_ids, node=0x825f6550) at ../../gcc/libiberty/splay-tree.c:242 #22 splay_tree_foreach (data=0x7fff64c7d520, fn=0x49dca0 lto_create_files_from_ids, node=0x825f6550) at ../../gcc/libiberty/splay-tree.c:566 #23 0x0049f53c in lto_file_read (count=0x7fff64c7d4f0, resolution_file=0x15b8ed0, file=0x23d9eac0) at ../../gcc/gcc/lto/lto.c:979 #24 read_cgraph_and_symbols (count=0x7fff64c7d4f0, resolution_file=0x15b8ed0, file=0x23d9eac0) at ../../gcc/gcc/lto/lto.c:2321 #25 lto_main (count=0x7fff64c7d4f0, resolution_file=0x15b8ed0, file=0x23d9eac0) at ../../gcc/gcc/lto/lto.c:2621 #26 0x006cf4aa in compile_file () at ../../gcc/gcc/toplev.c:570 #27 do_compile () at ../../gcc/gcc/toplev.c:1905 #28 toplev_main () at ../../gcc/gcc/toplev.c:1977 #29 0x2aff56c32a7d in __libc_start_main () from /lib64/libc.so.6 #30 0x00486c49 in _start () at ../sysdeps/x86_64/elf/start.S:113
[Bug fortran/48979] New: FRACTION und EXPONENT return invalid results for infinity/NaN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48979 Summary: FRACTION und EXPONENT return invalid results for infinity/NaN Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: thenl...@users.sourceforge.net program test_fractnan real, parameter :: pinfp = transfer(z'7F80', 0.0) real, parameter :: ninfp = transfer(z'FF80', 0.0) real, parameter :: nanp = transfer(z'7FD0', 0.0) real, parameter :: zerop = 0.0 real :: nan = nanp, pinf = pinfp, ninf = ninfp, zero = zerop print 100, zero, zero, fraction(zero), fraction(zero), exponent(zero) print 100, zerop, zerop, fraction(zerop), fraction(zerop), exponent(zerop) print 100, nan, nan, fraction(nan), fraction(nan), exponent(nan) print 100, nanp, nanp, fraction(nanp), fraction(nanp), exponent(nanp) print 100, ninf, ninf, fraction(ninf), fraction(ninf), exponent(ninf) print 100, ninfp, ninfp, fraction(ninfp), fraction(ninfp), exponent(ninfp) print 100, pinf, pinf, fraction(pinf), fraction(pinf), exponent(pinf) print 100, pinfp, pinfp, fraction(pinfp), fraction(pinfp), exponent(pinfp) 100 format (f10.5,1x,z8,1x,f10.5,1x,z8,1x,i11) end program test_fractnan Result: 0.000.00 0 0.000.00 0 NaN 7FD0NaN 7FD0 0 NaN 7FD00.00 0 -Infinity FF80 -Infinity FF80 0 -Infinity FF80NaN 7FC0 -2147483645 Infinity 7F80 Infinity 7F80 0 Infinity 7F80NaN 7FC0 -2147483645 Expected result (-std=f2003): 0.000.00 0 0.000.00 0 NaN 7FD0NaN 7FD0 2147483647 NaN 7FD0NaN 7FD0 2147483647 -Infinity FF80 -Infinity FF80 2147483647 -Infinity FF80 -Infinity FF80 2147483647 Infinity 7F80 Infinity 7F80 2147483647 Infinity 7F80 Infinity 7F80 2147483647 Expected result (-std=f2008): 0.000.00 0 0.000.00 0 NaN 7FD0NaN 7FD0 2147483647 NaN 7FD0NaN 7FD0 2147483647 -Infinity FF80NaN 7FC0 2147483647 -Infinity FF80NaN 7FC0 2147483647 Infinity 7F80NaN 7FC0 2147483647 Infinity 7F80NaN 7FC0 2147483647 EXPONENT(X) Fortran 2003/2008: If X is an IEEE infinity or NaN, the result has the value HUGE (0). FRACTION(X) Fortran 2003: If X is an IEEE infinity, the result is that infinity. If X is an IEEE NaN, the result is that NaN. Fortran 2008: If X is an IEEE NaN, the result is that NaN. If X is an IEEE infinity, the result is an IEEE NaN. Bug 1: The program does not compile without -fno-range-check. Bug 2: Different results are returned for a variables with values of NaN/Infinity and compile-time constants NaN/Infinity. Bug 3: EXPONENT should be HUGE(0)=2147483647 for NaN/Infinity.
[Bug tree-optimization/48822] [4.5/4.6 Regression] G++ gets stucks and never finishes compilation when enabling -O2/3 optimization options.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48822 --- Comment #8 from Richard Guenther rguenth at gcc dot gnu.org 2011-05-12 14:08:05 UTC --- Author: rguenth Date: Thu May 12 14:08:00 2011 New Revision: 173705 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=173705 Log: 2011-05-12 Richard Guenther rguent...@suse.de Backport from mainline 2011-05-02 Richard Guenther rguent...@suse.de PR tree-optimization/48822 * tree-ssa-sccvn.c (set_ssa_val_to): Never go up the lattice. (process_scc): Indicate which iteration we start. * gcc.dg/torture/pr48822.c: New testcase. Added: branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/torture/pr48822.c Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/testsuite/ChangeLog branches/gcc-4_6-branch/gcc/tree-ssa-sccvn.c
Re: [Bug lto/48978] New: excessive hash table allocation for large lto build
I tried a large LTO build with gcc version 4.7.0 20110511 (experimental) (GCC) on a 18GB machine. It ended with lto1: out of memory allocating 8589934312 bytes after a total of 6827421696 bytes Since a 7+GB single malloc seems somewhat excessive I put a break point on xmalloc_failed. It looks like the hash tables are growing too aggressively? I think the problem was introduced by Richi's last commit: 2011-05-12 Richard Guenther rguent...@suse.de * gimple.c (gtc_visit): Compare TREE_ADDRESSABLE, handle NULLPTR_TYPE similar to VOID_TYPE. Defer type-leader lookup until after simple checks. (gimple_types_compatible_p): Likewise. (iterative_hash_gimple_type): Always hash pointer targets and function return and argument types. (iterative_hash_canonical_type): Do not hash TYPE_QUALS, hash TYPE_ALIGN. Do not hash TYPE_MIN/MAX_VALUE. (gimple_canonical_types_compatible_p): Compare TREE_ADDRESSABLE, handle NULLPTR_TYPE similar to VOID_TYPE. Handle non-aggregates completely in the simple compare section. (gimple_register_canonical_type): Query the cache again after registering. So reverting this patch might get you past the problem. Ysterday I was able to build your testcase with 3GB of ram, today it got out of memory, too. The hashtable is not expanding too irrationally, but it saves O(n^2) information. I would like to see it die for sure ;) Honza
[Bug c++/48980] New: Misleading error message when a conversion is invalid while calling a protected base constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48980
Summary: Misleading error message when a conversion is invalid
while calling a protected base constructor
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: trivial
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dib...@ieee.org
Provided with this code:
class base {
protected:
base( int * ) {}
};
struct derived : base {
derived( const int * p ) : base( p ) {}
};
The compiler correctly detects that there is an error as using p as argument to
the constructor of base will break const-correctness. The error report
identifies that condition, but it also adds a misleading first error:
error.cpp: In constructor ‘derived::derived(const int*)’:
error.cpp:5: error: ‘base::base(int*)’ is protected
error.cpp:10: error: within this context
error.cpp:10: error: invalid conversion from ‘const int*’ to ‘int*’
error.cpp:10: error: initializing argument 1 of ‘base::base(int*)’
Clearly base::base(int*) is protected, but it is accessible from the context of
the constructor derived::derived(const int*), and the first 3 lines should not
be part of the error message.
This can be reproduced with the default g++ in ubuntu/linaro, and also with g++
4.0.3 (I don't know the exact compiler flags used, but I believe the error to
be independent of compiler flags, if it is not, I can find out the exact flags
used).
g++ (Ubuntu/Linaro 4.4.4-14ubuntu5) 4.4.5
[Bug lto/48978] excessive hash table allocation for large lto build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48978 --- Comment #1 from Jan Hubicka hubicka at ucw dot cz 2011-05-12 15:29:42 UTC --- I tried a large LTO build with gcc version 4.7.0 20110511 (experimental) (GCC) on a 18GB machine. It ended with lto1: out of memory allocating 8589934312 bytes after a total of 6827421696 bytes Since a 7+GB single malloc seems somewhat excessive I put a break point on xmalloc_failed. It looks like the hash tables are growing too aggressively? I think the problem was introduced by Richi's last commit: 2011-05-12 Richard Guenther rguent...@suse.de * gimple.c (gtc_visit): Compare TREE_ADDRESSABLE, handle NULLPTR_TYPE similar to VOID_TYPE. Defer type-leader lookup until after simple checks. (gimple_types_compatible_p): Likewise. (iterative_hash_gimple_type): Always hash pointer targets and function return and argument types. (iterative_hash_canonical_type): Do not hash TYPE_QUALS, hash TYPE_ALIGN. Do not hash TYPE_MIN/MAX_VALUE. (gimple_canonical_types_compatible_p): Compare TREE_ADDRESSABLE, handle NULLPTR_TYPE similar to VOID_TYPE. Handle non-aggregates completely in the simple compare section. (gimple_register_canonical_type): Query the cache again after registering. So reverting this patch might get you past the problem. Ysterday I was able to build your testcase with 3GB of ram, today it got out of memory, too. The hashtable is not expanding too irrationally, but it saves O(n^2) information. I would like to see it die for sure ;) Honza
[Bug libfortran/48982] New: libgfortran on sysv never uses fpsetmask
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48982
Summary: libgfortran on sysv never uses fpsetmask
Product: gcc
Version: 4.5.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libfortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: nicolai.sta...@zmaw.de
I'm working on Solaris10/SPARC.
nic@nic-desktop:~/gcc-4.5.3$ grep -r have_fpsetmask . | grep -v libgfor_
./libgfortran/configure.host:if test x${have_fpsetmask} = xyes; then
nic@nic-desktop:~/gcc-4.5.3$
have_fpsetmask won't ever be set anywhere.
libgfor_cv_have_fpsetmask ist set and should be tested instead.
This results in set_fpu coming from fpu-generic.h.
Compiling code w. -ffpe-trap=invalid,zero,overflow results in the following
warnings when executing the code:
Fortran runtime warning: IEEE 'invalid operation' exception not supported.
Fortran runtime warning: IEEE 'division by zero' exception not supported.
Fortran runtime warning: IEEE 'overflow' exception not supported.
Best regards
Nicolai
[Bug other/48981] New: bootstrap-lto -O3 produces miscompiled, broken gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48981
Summary: bootstrap-lto -O3 produces miscompiled, broken gcc
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: d.g.gorbac...@gmail.com
CC: rgue...@gcc.gnu.org
Host: i686-pc-linux-gnu
Target: i686-pc-linux-gnu
Build: i686-pc-linux-gnu
GCC crashes because of violation of strict aliasing rules. The same memory
location is accessed in vec_gc_o_reserve_1 through (struct vec_prefix *)
pointer, then in VEC_tree_base_quick_push through (struct VEC_tree_base *).
Optimization moves the code around in a wrong way.
This patch fixes it:
--- gcc/vec.c
+++ gcc/vec.c
@@ -37,11 +37,11 @@
struct vec_prefix
{
unsigned num;
unsigned alloc;
void *vec[1];
-};
+} __attribute__ ((may_alias));
#ifdef GATHER_STATISTICS
/* Store information about each particular vector. */
[Bug middle-end/45579] Re-enable IPA-CP for fn spec
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45579 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #1 from Jan Hubicka hubicka at gcc dot gnu.org 2011-05-12 15:35:08 UTC --- Hmm, it should be fairly trivial to update cgraph virtual cloning code to actually handle those attributes...
[Bug rtl-optimization/48971] [4.7 regression] ICE with -msoft-float -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48971 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added CC||law at redhat dot com, ||vmakarov at redhat dot com --- Comment #2 from Jeffrey A. Law law at redhat dot com 2011-05-12 15:14:54 UTC --- Vlad, this is an abort in setup_pressure_classes which apparently is totally broken for sparc -msoft-float.
[Bug c++/48980] Misleading error message when a conversion is invalid while calling a protected base constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48980 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-05-12 15:58:06 UTC --- With 4.6 you just get: d.cc: In constructor 'derived::derived(const int*)': d.cc:6:39: error: invalid conversion from 'const int*' to 'int*' [-fpermissive] d.cc:3:4: error: initializing argument 1 of 'base::base(int*)' [-fpermissive]
[Bug fortran/48979] FRACTION und EXPONENT return invalid results for infinity/NaN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48979 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org 2011-05-12 16:09:39 UTC --- (In reply to comment #0) Bug 1: The program does not compile without -fno-range-check. Can you explain why you think that this is a bug?
[Bug lto/48978] excessive hash table allocation for large lto build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48978 --- Comment #2 from Andi Kleen andi-gcc at firstfloor dot org 2011-05-12 16:16:19 UTC --- I will try. BTW this was a much larger test case (allyesconfig), the tarball I sent you is a much more limited config. Normally noone uses allyesconfig kernels (they barely boot), but they are a good stress tester for the compiler. Still I suspect the hash table expansion algorithms are not optimal. If you're already in the GB range you shouldn't be doubling anymore...
[Bug debug/48967] [4.6/4.7 Regression] ICE during use_narrower_mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48967 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-12 13:53:33 UTC --- Fixed.
[Bug other/48983] New: No diagnostic message about no space left on device with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48983
Summary: No diagnostic message about no space left on device
with LTO
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: d.g.gorbac...@gmail.com
To reproduce it in GNU/Linux:
# mount -t tmpfs tmpfs /mnt -o size=4k
$ cat 1.c
int main(void)
{
return 0;
}
^D
$ TMPDIR=/mnt gcc -flto 1.c
collect2: ld returned 1 exit status
[Bug lto/48978] excessive hash table allocation for large lto build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48978 --- Comment #3 from Andi Kleen andi-gcc at firstfloor dot org 2011-05-12 16:22:30 UTC --- looks like the revert is really needed, i just ran out of memory even on the small config on the large memory system.
[Bug other/48983] No diagnostic message about no space left on device with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48983 --- Comment #1 from Dmitry Gorbachev d.g.gorbachev at gmail dot com 2011-05-12 16:30:22 UTC --- Other not very informative messages (depending on the space and program size): /usr/bin/ld: fatal error: lto-wrapper failed collect2: ld returned 1 exit status lto-wrapper: gcc returned 1 exit status /usr/bin/ld: fatal error: lto-wrapper failed collect2: ld returned 1 exit status
[Bug fortran/48972] OPEN with Unicode file name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48972 --- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org 2011-05-12 17:40:32 UTC --- Author: burnus Date: Thu May 12 17:40:29 2011 New Revision: 173708 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=173708 Log: 2011-05-12 Tobias Burnus bur...@net-b.de PR fortran/48972 * resolve.c (resolve_intrinsic): Don't resolve module intrinsics multiple times. 2011-05-12 Tobias Burnus bur...@net-b.de PR fortran/48972 * gfortran.dg/iso_c_binding_compiler_3.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/iso_c_binding_compiler_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/48979] FRACTION und EXPONENT return invalid results for infinity/NaN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48979 --- Comment #2 from Thomas Henlich thenlich at users dot sourceforge.net 2011-05-12 17:34:27 UTC --- (In reply to comment #1) (In reply to comment #0) Bug 1: The program does not compile without -fno-range-check. Can you explain why you think that this is a bug? I consider it a bug because the result of the expressions FRACTION(Infinity) and FRACTION(NaN) is defined by the Fortran standard, so the compiler should not throw an error on simplifying them. Whether this really is a bug or not depends on whether one thinks that a standard-compliant Fortran program should compile without requiring special options (I do).
[Bug fortran/48979] FRACTION und EXPONENT return invalid results for infinity/NaN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48979 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2011-05-12 17:49:25 UTC --- (In reply to comment #2) Whether this really is a bug or not depends on whether one thinks that a standard-compliant Fortran program should compile without requiring special options (I do). So do I - but the question is whether it is standard conforming. NAN and INF are not Fortran numbers, cf. 13.4 Numeric models. Admittedly, IEEE and Fortran model numbers are widely mixed in the standard. However, strictly speaking, the IEEE functionality is only available if the relevant IEEE module is loaded and the feature is marked as supported. However, I have to admit that the error message should mention -fno-range-check; currently, it does not.
[Bug tree-optimization/48975] [4.6/4.7 Regression] ICE in execute_cse_reciprocals() with -fno-tree-slp-vectorize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48975 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-12 17:44:26 UTC --- Author: jakub Date: Thu May 12 17:44:23 2011 New Revision: 173709 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=173709 Log: PR tree-optimization/48975 * tree-if-conv.c (combine_blocks): Call free_bb_predicate on all bbs here and free and clear ifc_bbs at the end. * gcc.dg/pr48975.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr48975.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-if-conv.c
[Bug tree-optimization/48975] [4.6/4.7 Regression] ICE in execute_cse_reciprocals() with -fno-tree-slp-vectorize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48975 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-12 17:49:48 UTC --- Fixed.
[Bug tree-optimization/48975] [4.6/4.7 Regression] ICE in execute_cse_reciprocals() with -fno-tree-slp-vectorize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48975 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-12 17:46:21 UTC --- Author: jakub Date: Thu May 12 17:46:15 2011 New Revision: 173710 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=173710 Log: PR tree-optimization/48975 * tree-if-conv.c (combine_blocks): Call free_bb_predicate on all bbs here and free and clear ifc_bbs at the end. * gcc.dg/pr48975.c: New test. Added: branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/pr48975.c Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/testsuite/ChangeLog branches/gcc-4_6-branch/gcc/tree-if-conv.c
[Bug rtl-optimization/48971] [4.7 regression] ICE with -msoft-float -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48971 --- Comment #3 from Vladimir Makarov vmakarov at redhat dot com 2011-05-12 17:57:58 UTC --- (In reply to comment #2) Vlad, this is an abort in setup_pressure_classes which apparently is totally broken for sparc -msoft-float. I found the wrong code. It is pretty simple but I need to check a few platforms because the fix might affect other platform builds. I hope I'll send the patch at the end of the day.
[Bug fortran/48972] OPEN with Unicode file name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48972 --- Comment #6 from Tobias Burnus burnus at gcc dot gnu.org 2011-05-12 17:44:21 UTC --- (In reply to comment #5) New Revision: 173708 Wrong PR number - supposed to go to PR 45823
[Bug fortran/45823] Bogus warning for intrinsic module procedures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45823 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2011-05-12 17:45:15 UTC --- FIXED. Commit had the wrong PR number: URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=173708 Log: 2011-05-12 Tobias Burnus bur...@net-b.de PR fortran/48972 * resolve.c (resolve_intrinsic): Don't resolve module intrinsics multiple times. 2011-05-12 Tobias Burnus bur...@net-b.de PR fortran/48972 * gfortran.dg/iso_c_binding_compiler_3.f90: New.
[Bug fortran/48979] FRACTION und EXPONENT return invalid results for infinity/NaN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48979 --- Comment #4 from Steve Kargl sgk at troutmask dot apl.washington.edu 2011-05-12 18:21:46 UTC --- On Thu, May 12, 2011 at 05:53:10PM +, thenlich at users dot sourceforge.net wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48979 --- Comment #2 from Thomas Henlich thenlich at users dot sourceforge.net 2011-05-12 17:34:27 UTC --- (In reply to comment #1) (In reply to comment #0) Bug 1: The program does not compile without -fno-range-check. Can you explain why you think that this is a bug? I consider it a bug because the result of the expressions FRACTION(Infinity) and FRACTION(NaN) is defined by the Fortran standard, so the compiler should not throw an error on simplifying them. Whether this really is a bug or not depends on whether one thinks that a standard-compliant Fortran program should compile without requiring special options (I do). You're looking at the wrong standard. Gfortran is a Fortran 95 compiler (yes, it has many F03 and F08 extensions). The Fortran 95 standard states: 13.14.38 FRACTION(X) Result Value. The result has the value X*b**(-e), where b and e are as defined in 13.7.1 for the model representation of X. If X has the value zero, the result has the value zero. Neither NaN nor +-Inf can be represented as a model number.
[Bug libfortran/48960] OPEN statement modifies NEWUNIT variable on error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48960 Jerry DeLisle jvdelisle at gcc dot gnu.org changed: What|Removed |Added AssignedTo|unassigned at gcc dot |jvdelisle at gcc dot |gnu.org |gnu.org --- Comment #1 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2011-05-12 18:31:56 UTC --- Ok, on my list
[Bug other/48981] bootstrap-lto -O3 produces miscompiled, broken gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48981 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2011-05-12 17:59:56 UTC --- Created attachment 24239 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24239 Patch which changes how vec base is done Can you try this patch? I have not tested it and have not even tried compiling it.
[Bug fortran/48976] INQUIRE with STREAM= not supported
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48976 Jerry DeLisle jvdelisle at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.05.12 18:45:19 AssignedTo|unassigned at gcc dot |jvdelisle at gcc dot |gnu.org |gnu.org Ever Confirmed|0 |1 --- Comment #1 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2011-05-12 18:45:19 UTC --- I seem to recall this use to work. We need to check to see if this is a regression.
[Bug fortran/48972] OPEN with Unicode file name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48972 --- Comment #7 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2011-05-12 18:39:19 UTC --- Reply to comment#2, There are tags that are constants and some that are variable expressions, so you have to resolve the correct one. I have not looked for a while , but I think there is a resolve_tag_e or such.
[Bug c/48968] incorrect warning about longjmp/vfork clobbering a local (-W -O2, x86-64)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48968 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-12 18:55:39 UTC --- read_char calls setjmp.
[Bug fortran/48976] INQUIRE with STREAM= not supported
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48976 --- Comment #2 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2011-05-12 19:04:46 UTC --- OK, I checked. We simply have not implemented this yet. I will do so.
[Bug fortran/48979] FRACTION und EXPONENT return invalid results for infinity/NaN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48979 --- Comment #5 from Steve Kargl sgk at troutmask dot apl.washington.edu 2011-05-12 18:47:54 UTC --- On Thu, May 12, 2011 at 05:59:44PM +, burnus at gcc dot gnu.org wrote: Whether this really is a bug or not depends on whether one thinks that a standard-compliant Fortran program should compile without requiring special options (I do). So do I - but the question is whether it is standard conforming. NAN and INF are not Fortran numbers, cf. 13.4 Numeric models. Admittedly, IEEE and Fortran model numbers are widely mixed in the standard. However, strictly speaking, the IEEE functionality is only available if the relevant IEEE module is loaded and the feature is marked as supported. From F2003: Page 300: A program is prohibited from invoking an intrinsic procedure under circumstances where a value to be returned in a subroutine argument or function result is outside the range of values representable by objects of the specified type and type parameters, unless the intrinsic module IEEE_ARITHMETIC (section 14) is accessible and there is support for an infinite or a NaN result, as appropriate. Page 364: The intrinsic modules IEEE_EXCEPTIONS, IEEE_ARITHMETIC, and IEEE_FEATURES provide support for exceptions and IEEE arithmetic. Whether the modules are provided is processor dependent. 1) Thomas's program does not USE IEEE_ARITHMETIC. 2) gfortran does not supply the ieee modules. So, calling fraction() with +-Inf and NaN is, I believe, technically non-conforming. I agree that having consistency between constant-folding and runtime results is desirable, I disagree on calling the need for -fno-range-check a bug.
[Bug fortran/48979] FRACTION und EXPONENT return invalid results for infinity/NaN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48979
--- Comment #6 from Steve Kargl sgk at troutmask dot apl.washington.edu
2011-05-12 19:18:16 UTC ---
On Thu, May 12, 2011 at 07:03:34PM +, sgk at troutmask dot
apl.washington.edu wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48979
--- Comment #5 from Steve Kargl sgk at troutmask dot apl.washington.edu
2011-05-12 18:47:54 UTC ---
On Thu, May 12, 2011 at 05:59:44PM +, burnus at gcc dot gnu.org wrote:
Whether this really is a bug or not depends on whether one thinks that a
standard-compliant Fortran program should compile without requiring
special
options (I do).
So do I - but the question is whether it is standard conforming. NAN and INF
are not Fortran numbers, cf. 13.4 Numeric models. Admittedly, IEEE and
Fortran model numbers are widely mixed in the standard. However, strictly
speaking, the IEEE functionality is only available if the relevant IEEE
module
is loaded and the feature is marked as supported.
From F2003:
Page 300:
A program is prohibited from invoking an intrinsic procedure
under circumstances where a value to be returned in a subroutine
argument or function result is outside the range of values
representable by objects of the specified type and type parameters,
unless the intrinsic module IEEE_ARITHMETIC (section 14) is accessible
and there is support for an infinite or a NaN result, as appropriate.
Page 364:
The intrinsic modules IEEE_EXCEPTIONS, IEEE_ARITHMETIC, and
IEEE_FEATURES provide support for exceptions and IEEE arithmetic.
Whether the modules are provided is processor dependent.
1) Thomas's program does not USE IEEE_ARITHMETIC.
2) gfortran does not supply the ieee modules.
So, calling fraction() with +-Inf and NaN is, I believe,
technically non-conforming.
I agree that having consistency between constant-folding
and runtime results is desirable, I disagree on calling the
need for -fno-range-check a bug.
Index: simplify.c
===
--- simplify.c (revision 173705)
+++ simplify.c (working copy)
@@ -2328,6 +2328,12 @@ gfc_simplify_fraction (gfc_expr *x)
result = gfc_get_constant_expr (BT_REAL, x-ts.kind, x-where);
+ if (mpfr_nan_p (x-value.real) != 0 || mpfr_inf_p (x-value.real) != 0)
+{
+ mpfr_set (result-value.real, x-value.real, GFC_RND_MODE);
+ return result;
+}
+
if (mpfr_sgn (x-value.real) == 0)
{
mpfr_set_ui (result-value.real, 0, GFC_RND_MODE);
gives
0.000.00 0
0.000.00 0
NaN 7FD0NaN 7FD0 0
NaN 7FD0NaN 7FC0 0
-Infinity FF80 -Infinity FF80 0
-Infinity FF80 -Infinity FF80 3
Infinity 7F80 Infinity 7F80 0
Infinity 7F80 Infinity 7F80 3
fixing exponent is much more involved.
[Bug lto/48947] 4.6.0 fails to link ffmpeg with LTO and gold
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48947 Ian Lance Taylor ian at airs dot com changed: What|Removed |Added CC||ian at airs dot com --- Comment #6 from Ian Lance Taylor ian at airs dot com 2011-05-12 19:36:23 UTC --- I believe that gold will issue these warnings in some cases that GNU ld will not, but as far as I know gold will never issue them for code which was in fact compiled with -fPIC. Can you get a copy of a failing ltransNN.ltrans.o and attach it here, or at least attach the output of readelf -r on the file?
[Bug fortran/48977] -fpe-trap=denormal on x86 GLIBC systems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48977
--- Comment #1 from Uros Bizjak ubizjak at gmail dot com 2011-05-12 19:43:56
UTC ---
Why not just:
Index: configure.host
===
--- configure.host(revision 173705)
+++ configure.host(working copy)
@@ -20,12 +20,6 @@
# DEFAULTS
fpu_host='fpu-generic'
-# HOST-SPECIFIC OVERRIDES
-case ${host_cpu} in
- i?86 | x86_64)
-fpu_host='fpu-387' ;;
-esac
-
# CONFIGURATION-SPECIFIC OVERRIDES
if test x${have_feenableexcept} = xyes; then
fpu_host='fpu-glibc'
@@ -39,6 +33,12 @@
fpu_host='fpu-aix'
fi
+# HOST-SPECIFIC OVERRIDES
+case ${host_cpu} in
+ i?86 | x86_64)
+fpu_host='fpu-387' ;;
+esac
+
# Some targets require additional compiler options for NaN/Inf.
ieee_flags=
case ${host_cpu} in
[Bug c/48968] incorrect warning about longjmp/vfork clobbering a local (-W -O2, x86-64)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48968 --- Comment #5 from eggert at gnu dot org 2011-05-12 19:52:20 UTC --- A register may be live (after inlining), but the local variable XXXevent is not live across the setjmp call, so surely the warning is wrong even if the generated code is correct.
[Bug middle-end/48984] New: [4.7 Regression] Many testsuite failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48984 Summary: [4.7 Regression] Many testsuite failures Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com On Linux/ia32, revision 173711: http://gcc.gnu.org/ml/gcc-cvs/2011-05/msg00490.html caused: FAIL: gcc.dg/pr45055.c (test for excess errors) FAIL: gcc.dg/tree-ssa/vrp47.c scan-tree-dump-times dom1 x[^ ]* y 1 FAIL: gfortran.dg/block_name_1.f90 -O (internal compiler error) FAIL: gfortran.dg/block_name_1.f90 -O (test for excess errors) FAIL: gfortran.dg/dependency_23.f90 -O0 (internal compiler error) FAIL: gfortran.dg/dependency_23.f90 -O0 (test for excess errors) FAIL: gfortran.dg/dependency_23.f90 -O1 (internal compiler error) FAIL: gfortran.dg/dependency_23.f90 -O1 (test for excess errors) FAIL: gfortran.dg/dependency_23.f90 -O2 (internal compiler error) FAIL: gfortran.dg/dependency_23.f90 -O2 (test for excess errors) FAIL: gfortran.dg/dependency_23.f90 -O3 -fomit-frame-pointer (internal compiler error) FAIL: gfortran.dg/dependency_23.f90 -O3 -fomit-frame-pointer (test for excess errors) FAIL: gfortran.dg/dependency_23.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (internal compiler error) FAIL: gfortran.dg/dependency_23.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) FAIL: gfortran.dg/dependency_23.f90 -O3 -fomit-frame-pointer -funroll-loops (internal compiler error) FAIL: gfortran.dg/dependency_23.f90 -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) FAIL: gfortran.dg/dependency_23.f90 -O3 -g (internal compiler error) FAIL: gfortran.dg/dependency_23.f90 -O3 -g (test for excess errors) FAIL: gfortran.dg/dependency_23.f90 -Os (internal compiler error) FAIL: gfortran.dg/dependency_23.f90 -Os (test for excess errors) FAIL: gfortran.dg/gomp/pr39152.f90 -O (internal compiler error) FAIL: gfortran.dg/gomp/pr39152.f90 -O (test for excess errors) FAIL: gfortran.dg/where_1.f90 -O0 (internal compiler error) FAIL: gfortran.dg/where_1.f90 -O0 (test for excess errors) FAIL: gfortran.dg/where_1.f90 -O1 (internal compiler error) FAIL: gfortran.dg/where_1.f90 -O1 (test for excess errors) FAIL: gfortran.dg/where_1.f90 -O2 (internal compiler error) FAIL: gfortran.dg/where_1.f90 -O2 (test for excess errors) FAIL: gfortran.dg/where_1.f90 -O3 -fomit-frame-pointer (internal compiler error) FAIL: gfortran.dg/where_1.f90 -O3 -fomit-frame-pointer (test for excess errors) FAIL: gfortran.dg/where_1.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (internal compiler error) FAIL: gfortran.dg/where_1.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) FAIL: gfortran.dg/where_1.f90 -O3 -fomit-frame-pointer -funroll-loops (internal compiler error) FAIL: gfortran.dg/where_1.f90 -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) FAIL: gfortran.dg/where_1.f90 -O3 -g (internal compiler error) FAIL: gfortran.dg/where_1.f90 -O3 -g (test for excess errors) FAIL: gfortran.dg/where_1.f90 -Os (internal compiler error) FAIL: gfortran.dg/where_1.f90 -Os (test for excess errors) FAIL: gfortran.dg/where_nested_1.f90 -O (internal compiler error) FAIL: gfortran.dg/where_nested_1.f90 -O (test for excess errors) FAIL: gfortran.dg/where_operator_assign_1.f90 -O (internal compiler error) FAIL: gfortran.dg/where_operator_assign_1.f90 -O (test for excess errors) FAIL: gfortran.dg/where_operator_assign_2.f90 -O (internal compiler error) FAIL: gfortran.dg/where_operator_assign_2.f90 -O (test for excess errors) FAIL: gfortran.dg/where_operator_assign_3.f90 -O (internal compiler error) FAIL: gfortran.dg/where_operator_assign_3.f90 -O (test for excess errors) FAIL: gfortran.fortran-torture/execute/inquire_5.f90, -O0 (internal compiler error) FAIL: gfortran.fortran-torture/execute/inquire_5.f90, -O1 (internal compiler error) FAIL: gfortran.fortran-torture/execute/inquire_5.f90, -O2 (internal compiler error) FAIL: gfortran.fortran-torture/execute/inquire_5.f90, -O2 -fbounds-check (internal compiler error) FAIL: gfortran.fortran-torture/execute/inquire_5.f90, -O2 -fomit-frame-pointer -finline-functions (internal compiler error) FAIL: gfortran.fortran-torture/execute/inquire_5.f90, -O2 -fomit-frame-pointer -finline-functions -funroll-loops (internal compiler error) FAIL: gfortran.fortran-torture/execute/inquire_5.f90, -O3 -g (internal compiler error) FAIL: gfortran.fortran-torture/execute/inquire_5.f90, -Os (internal compiler error) FAIL: gfortran.fortran-torture/execute/inquire_5.f90, -O2 -ftree-vectorize -msse2 (internal compiler error) FAIL: gfortran.fortran-torture/execute/intrinsic_associated_2.f90, -O0 (internal compiler error) FAIL:
[Bug fortran/48979] FRACTION und EXPONENT return invalid results for infinity/NaN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48979
--- Comment #7 from Steve Kargl sgk at troutmask dot apl.washington.edu
2011-05-12 20:10:19 UTC ---
Here's a better patch that gets the warning/error
messages correct.
Index: simplify.c
===
--- simplify.c (revision 173705)
+++ simplify.c (working copy)
@@ -2328,6 +2328,12 @@ gfc_simplify_fraction (gfc_expr *x)
result = gfc_get_constant_expr (BT_REAL, x-ts.kind, x-where);
+ if (mpfr_nan_p (x-value.real) != 0 || mpfr_inf_p (x-value.real) != 0)
+{
+ mpfr_set (result-value.real, x-value.real, GFC_RND_MODE);
+ return range_check (result, FRACTION);
+}
+
if (mpfr_sgn (x-value.real) == 0)
{
mpfr_set_ui (result-value.real, 0, GFC_RND_MODE);
[Bug middle-end/48984] [4.7 Regression] Many testsuite failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48984 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2011-05-12 20:12:45 UTC --- bool in fortran can be multiple sizes.
[Bug fortran/48979] FRACTION und EXPONENT return invalid results for infinity/NaN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48979 --- Comment #8 from Tobias Burnus burnus at gcc dot gnu.org 2011-05-12 20:36:05 UTC --- (In reply to comment #7) + return range_check (result, FRACTION); Can we additionally add to the range_check() error messages a note like This check can be disabled with the option -fno-range-check? We already did so at several places. I think without, one does not know that one can easily disable it. An alternative would be to switch to the middle-end way of showing warning messages: warning: unused variable 'x' [-Wunused-variable] Analogously, the error could then be [-frange-check].
[Bug fortran/48972] OPEN with Unicode file name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48972 --- Comment #8 from Janne Blomqvist jb at gcc dot gnu.org 2011-05-12 21:02:40 UTC --- (In reply to comment #4) (In reply to comment #3) - Specify that the default character set is UTF-8. What do you mean by that? I know 1 byte and 4 byte character variables, but I do not see where UTF-8 fits in there. (One can place UTF-8 into character(kind=1) - and it also kind of works OK. But if one wants to use len(), string manipulation (change 3 character to ...), or tabulated I/O that will fail. But as quirky workaround, one can use UTF-8 file names with kind=1 character variables - at least under Unix/Linux.) Well, for backwards compatibility I strongly think we should keep kind=1 the default. What I meant was that for bytes whose values are not part of the 7-bit ASCII character set, we can interpret it as UTF-8, as UTF-8 is backwards compatible with ASCII. In most cases this won't matter, but it matters e.g. as discussed in this PR on mingw as we need to convert the default character filename to utf-16. The other option, I suppose, would be to regard the default character set as some locale-dependent charset, and then use some char-wchar_t conversion routines from the MS libc, assuming such things exist. FWIW, the issue that the length of a string does not equal the width when printed is not unique to utf-8. The same issue is seen with kind=4 (utf-32) as well e.g. if one uses diacritic characters. So regardless of whether one uses UTF-8, UTF-16 or UTF-32, with unicode one needs to be prepared for the fact that the number of code points in a string might not be the same as the width. Fortran is not really prepared for this, so I suppose that making the string intrinsics etc. consider bytes==characters (for kind=1) is the best we can do in any case. Regarding the ENCODING= specifier: That's already used for the encoding of the file content - one shan't use it to also modify the interpretation of the FILE string. Yes, the point was not related to the FILE= issue. Rather, that if we make utf-8 the default charset then it makes sense to also make the default file encoding utf-8. I still think that the default character encoding should remain 1 byte (kind=1), which is simply passed as is to open(). Yes, I agree, at least for Unix. What about mingw, then, if the string contains characters not part of the 7-bit ASCII charset? Will MS libc convert it into UTF-16 assuming the encoding is according to the current locale, or what? And UCS-4 as FILE= argument should simply be supported as vendor extension. One just needs to tell the library that the string is in UCS-4. I'm not convinced of the value of such an extension. Fortran already suffers from too many vendor extensions. This wide string could then directly used for Windows' _wopen Not really, since wchar_t on windows is a 16-bit type (utf-16), not a 32-bit one. or converted to UTF-8 for Unix/Linux. Well, that is also a choice that needs to be made, analogous on how to convert default char file names to utf-16 on mingw. That is, do we convert the name to UTF-8 or to whatever the charset of the current locale is (LC_CTYPE)? So in one way it would be nice to make gfortran respect the current locale charset, but OTOH Unicode was invented because the locale charset system is a failure, and just using unicode everywhere would in some respects be simpler.
[Bug fortran/48979] FRACTION und EXPONENT return invalid results for infinity/NaN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48979
--- Comment #10 from Steve Kargl sgk at troutmask dot apl.washington.edu
2011-05-12 20:54:38 UTC ---
Forgot the diff
Index: simplify.c
===
--- simplify.c (revision 173705)
+++ simplify.c (working copy)
@@ -2328,6 +2328,14 @@ gfc_simplify_fraction (gfc_expr *x)
result = gfc_get_constant_expr (BT_REAL, x-ts.kind, x-where);
+ if (mpfr_nan_p (x-value.real) != 0 || mpfr_inf_p (x-value.real) != 0)
+{
+ mpfr_set (result-value.real, x-value.real, GFC_RND_MODE);
+ if (gfc_option.allow_std (GFC_STD_F2008|GFC_STD_F2003))
+ return result;
+ return range_check (result, FRACTION);
+}
+
if (mpfr_sgn (x-value.real) == 0)
{
mpfr_set_ui (result-value.real, 0, GFC_RND_MODE);
[Bug fortran/48979] FRACTION und EXPONENT return invalid results for infinity/NaN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48979 --- Comment #9 from Steve Kargl sgk at troutmask dot apl.washington.edu 2011-05-12 20:53:37 UTC --- On Thu, May 12, 2011 at 08:40:48PM +, burnus at gcc dot gnu.org wrote: (In reply to comment #7) + return range_check (result, FRACTION); Can we additionally add to the range_check() error messages a note like This check can be disabled with the option -fno-range-check? We already did so at several places. I think without, one does not know that one can easily disable it. An alternative would be to switch to the middle-end way of showing warning messages: warning: unused variable 'x' [-Wunused-variable] Analogously, the error could then be [-frange-check]. I worked up the following patch. It now silently accepts fraction() for +-inf and nan for -std=gnu,f2003,f2008. If one uses -std=f95, you get a bunch of noise. I'll finish a patch on Saturday. EXPONENT() is going to be a little more work. When simplication does not apply, gfortran uses something like integer(kind=4) D.1559; integer(kind=4) D.1558; __builtin_frexpf (nan, D.1558); D.1559 = D.1558; _gfortran_transfer_integer_write (dt_parm.2, D.1559, 4); to grab the fraction and exponent. For nan and +-inf, D.1558 is 0.
[Bug other/44574] Avoid use of atoi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44574 --- Comment #2 from Joseph S. Myers jsm28 at gcc dot gnu.org 2011-05-12 21:08:14 UTC --- There are also uses of atol, atoll and atoq to eliminate. Also note some Ada code using atoi (surely there must be a more idiomatic Ada way of doing this?). It would be best to poison all these functions when the uses are eliminated. In some cases the use of atoi may be allowing a wider range of inputs (in terms of leading whitespace and trailing unrecognized characters) than should actually be allowed in the context. libiberty has a use of atoi in cplus-dem.c that is harmless (it's only used on a single-digit string) but pointless (C guarantees that the digit characters have consecutive integer values so you can just subtract '0', and this guarantee is already in C90).
