--- Comment #8 from burnus at gcc dot gnu dot org 2008-07-28 06:41 ---
I see only one place in the I/O library that uses GFC_DTYPE_RANK_MASK.
There are many many places in the intrinsics.
Hmm, true. Maybe one should disable the rank 15 in the frontend again. I see
GFC_DESCRIPTOR used
--- Comment #10 from dodji at gcc dot gnu dot org 2008-07-28 07:19 ---
Created an attachment (id=15968)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15968action=view)
try scanning DECL_EXPR instead of VAR_DECLs directly.
@Jason: I have tried scanning DECL_EXPR and setting only
--- Comment #9 from tkoenig at gcc dot gnu dot org 2008-07-28 09:46 ---
See
http://gcc.gnu.org/wiki/ArrayDescriptorUpdate
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from tkoenig at gcc dot gnu dot org 2008-07-28 09:52 ---
Another test case:
$ cat foo.f90
program main
real, dimension(2,2) :: a
real, dimension(2) :: b
call random_number(a)
b = sum(a,dim=1) + 0.4
end program main
$ gfortran -Warray-temporaries foo.f90
--- Comment #2 from tkoenig at gcc dot gnu dot org 2008-07-28 10:38 ---
No temporary is done if the first argument of the
matmul intrinsic is a (3,3) array.
Interesting.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from tkoenig at gcc dot gnu dot org 2008-07-28 10:38 ---
Confirmed.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from tkoenig at gcc dot gnu dot org 2008-07-28 10:48 ---
Why a run-time check?
AFAIK, we can always determine the rank at runtime, so unless somebody messes
with our array descriptors big time, we should be safe.
--
tkoenig at gcc dot gnu dot org changed:
--- Comment #11 from dodji at gcc dot gnu dot org 2008-07-28 10:52 ---
Created an attachment (id=15969)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15969action=view)
update vars more specifically, adding BIND_EXPR
After talking with Jakub, it appeared that I was forgetting to
--- Comment #8 from tim at bishnet dot net 2008-07-28 10:52 ---
For what it's worth, I just wanted to add a me too. I'm building on Solaris 9
sparc using gcc 4.2.4 to build with. The error occurs with 4.3.1 and the
20080724 snapshot.
/u1/src/garstow/devel/gcc/work/build/./prev-gcc/xgcc
Hello,
I am working on a larger project processing audio signals in double format. As
I needed to estimate the max. Amplitude of a buffer, it returned a faulty
value.
I debugged the assembler code and realized, that the optimizer created a faulty
computation of the maximum. By only changing one
--- Comment #2 from j dot wookey at bristol dot ac dot uk 2008-07-28 11:02
---
Updating gfortran to 4.4.0 (20080728) on i386-apple-darwin9.4.0 fixes problem.
Thanks for looking at it!
--
j dot wookey at bristol dot ac dot uk changed:
What|Removed
Hello,
I am working on a larger project processing audio signals in double format. As
I needed to estimate the max. Amplitude of a buffer, it returned a faulty
value.
I debugged the assembler code and realized, that the optimizer created a faulty
computation of the maximum. By only changing one
--- Comment #1 from tcm dot home at gmx dot de 2008-07-28 11:15 ---
Created an attachment (id=15970)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15970action=view)
File generated with g++ -o factor -v -save-temps -Wall -O2 -march=i686
factor.cpp
--
--- Comment #3 from burnus at gcc dot gnu dot org 2008-07-28 11:21 ---
Why a run-time check?
Because the shape might not be known at compile time? And a compile-time check
because compile-time checks are nicer ;-)
AFAIK, we can always determine the rank at runtime
Yes, the RANK
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36652
--- Comment #1 from tcm dot home at gmx dot de 2008-07-28 11:49 ---
*** This bug has been marked as a duplicate of 36953 ***
--
tcm dot home at gmx dot de changed:
What|Removed |Added
--- Comment #2 from tcm dot home at gmx dot de 2008-07-28 11:49 ---
*** Bug 36952 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36953
--- Comment #1 from tomby at gcc dot gnu dot org 2008-07-28 11:53 ---
Created an attachment (id=15971)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15971action=view)
Testcase where loop distribution enabled makes run of binary forever
Compilation with CFLAGS=-O2 and running of
--- Comment #1 from michael dot a dot richmond at nasa dot gov 2008-07-28
12:23 ---
I get the same error in gcc-4.4-20080725 under MIPS Linux. My last successful
bootstrap was 20080718.
--
michael dot a dot richmond at nasa dot gov changed:
What|Removed
compiling the following functions with g++ -Wlogical-op leads to a wrong
warning
-
templateclass C void Test()
{
if ((1 == 2) || (true)) { // warning: logical #8216;||#8217; with
non-zero constant will always evaluate as true
}
if ((1 == 2) || (!false)) {
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-07-28 13:12 ---
I can reproduce this with 4.2.4, but not with 4.1.3 or 4.3.1.
-fno-strict-aliasing fixes it, so I suspect it's a dup of one of the known
wrong-code
bugs with GCC 4.2.x
--
rguenth at gcc dot gnu dot org changed:
--- Comment #2 from hjl dot tools at gmail dot com 2008-07-28 13:42 ---
Have you tried revision 138154 or newer?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36919
--- Comment #3 from michael dot a dot richmond at nasa dot gov 2008-07-28
13:49 ---
(In reply to comment #2)
Have you tried revision 138154 or newer?
I don't know what that is
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36919
--- Comment #12 from jakub at gcc dot gnu dot org 2008-07-28 15:00 ---
There are unneeded {} pairs, when there is just one statement in for/if, you
should just write
if (something)
DECL_CONTEXT (x) = current_function_decl;
and similar for
for (.)
if (something)
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-07-28 15:35 ---
They have been all XFAILed, with the tuples merge we now get
XPASS: gcc.dg/tree-ssa/data-dep-1.c scan-tree-dump-times ltrans 4, \\+, 1 0
XPASS: gcc.dg/tree-ssa/ltrans-3.c scan-tree-dump-times ltrans transformed
--- Comment #20 from rguenth at gcc dot gnu dot org 2008-07-28 16:15
---
I can reproduce this on the trunk after the tuples merge (i686).
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from michael dot a dot richmond at nasa dot gov 2008-07-28
16:23 ---
(In reply to comment #2)
Have you tried revision 138154 or newer?
Revision 138154 fixed the problem
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36919
--- Comment #13 from dodji at gcc dot gnu dot org 2008-07-28 17:01 ---
Created an attachment (id=15972)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15972action=view)
reworked patch
Reworked patch to walk BIND_EXPR_VARs only. I think there is no need to walk
VAR_DECLs via
This testcase (yes, it's actually huge):
#include iostream
int
main ()
{
std::cerr writing to cerr std::endl;
}
segfaults in libstdc++ when powerpc-linux mainline GCC is configured with
--enable-secureplt and uses 2.16 binutils (specifically, I used 2.16.91.0.5
20051219 (SUSE
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-07-28 17:47 ---
Blah. This makes little sense really though, the generated code should be
exactly the same before and after.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
On Linux/x86, revision 138207 causes
+FAIL: gcc.dg/format/bitfld-1.c -DWIDE (test for excess errors)
+FAIL: gcc.dg/format/bitfld-1.c (test for excess errors)
+FAIL: gcc.dg/matrix/matrix-1.c scan-ipa-dump-times matrix-reorg Flattened 3
dimensions 1: dump file does not exist
+FAIL:
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-07-28 18:15 ---
The matrix ones are expected. I guess you really don't read the mailing list
about the trunk being frozen.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36956
gcc version 4.4.0 20080728 (experimental) [trunk revision 138209] (GCC)
COLLECT_GCC_OPTIONS='-c' '-B/home/guerby/build/gcc/' '-gnatws' '-O1'
'-I/home/guerby/build/gcc/testsuite/ada/acats/support' '-v' '-gnatez'
'-mtune=generic'
/home/guerby/build/gcc/gnat1
-I/home/guerby/build/gcc/testsuite/ada
--- Comment #1 from laurent at guerby dot net 2008-07-28 18:29 ---
(gdb) f 2
#2 0x007886d4 in emit_move_insn (x=0x2b6f9e60, y=0x2b6f9d40)
at ../../trunk/gcc/expr.c:3380
3380 gcc_assert (mode != BLKmode
(gdb) debug_rtx(x)
Undefined command: debug_rtx. Try help.
--- Comment #2 from laurent at guerby dot net 2008-07-28 18:29 ---
(reg:HI 59 [ T12b ])
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36957
--- Comment #4 from domob at gcc dot gnu dot org 2008-07-28 18:41 ---
Thanks for all the hints, Tobias! I've had a look through the F2003 standard
about intrinsics taking optional char arguments, and it seems as though PACK
and RESHAPE would suffer from the same problem as EOSHIFT does
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |domob at gcc dot gnu dot org
|dot org
--- Comment #19 from lothar at tradescape dot biz 2008-07-28 18:55 ---
Created an attachment (id=15973)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15973action=view)
oprofile logs
I compiled optimized executables with and without -fno-strict-aliasing and
generated an oprofile
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-07-28 19:19 ---
The problem is that the cast in
item = (ce3801b__B_1__fix_io__num___XF_1_10_1_16) iftmp.130;
is stripped away. item (QImode) is of type
type integer_type 0xb7da3000 ce3801b__B_1__fix_io__num___XF_1_10_1_16
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-07-28 19:21 ---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from burnus at gcc dot gnu dot org 2008-07-28 20:04 ---
and it seems as though PACK and RESHAPE would suffer from the same problem as
EOSHIFT does
Seems so. I glanced through F2008 CD but I could not find more potential
problems.
Is it ok if I try to write one
--- Comment #3 from jwakely dot gcc at gmail dot com 2008-07-28 20:27
---
(In reply to comment #2)
Jonathan, can you have a look? If you can confirm the issue, is it just matter
of adding a call to __enable_shared_from_this_helper(_M_refcount, _M_ptr,
_M_ptr) to
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-07-28 20:33 ---
Subject: Bug 36957
Author: rguenth
Date: Mon Jul 28 20:32:32 2008
New Revision: 138217
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=138217
Log:
2008-07-28 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-07-28 20:33 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from steven at gcc dot gnu dot org 2008-07-28 20:41 ---
Like Pinski said: the code before and after the patch should be identical
w.r.t. TLS addresses. Without a more specific test case I'm not even going to
look at this.
--
steven at gcc dot gnu dot org changed:
There are many fr.po files in which the word sans has been misleadingly typed
sasn.
:!find . -name fr.po -exec grep -in sasn {} /dev/null \;
./gcc/po/fr.po:18353:msgstr %Jd#65533;claration de #65533; %D #65533; sasn
lien suivant une d#65533;claration externe
./gcc/po/fr.po:21788:msgstr
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dodji at gcc dot gnu dot org
|dot org
--- Comment #1 from joseph at codesourcery dot com 2008-07-28 20:53 ---
Subject: Re: typos in french translation.
Translation fixes must go to the language teams. We make no local changes
to the .po files, only import unmodified new versions from the TP.
--
--- Comment #3 from janis at gcc dot gnu dot org 2008-07-28 21:17 ---
Created an attachment (id=15974)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15974action=view)
disassembly of eh_globals.o before aptch
File libstdc++-v3/libsupc++/eh_globals.cc is compiled differently before
--- Comment #4 from janis at gcc dot gnu dot org 2008-07-28 21:19 ---
Created an attachment (id=15975)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15975action=view)
disassembly of eh_globals.o after patch
This attachment is the disassembly with the patch.
--
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-07-28 21:28 ---
Hmm, is this with the relocs?
The first thing I noticed is that the loading of the global address is
different.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36955
--- Comment #6 from janis at gcc dot gnu dot org 2008-07-28 21:32 ---
The attachments are the output of objdump -d (2.16 objdump) of eh_globals.o
in the build trees for r135960 and r135961. Let me know if there are things
you'd like me to try.
--
--- Comment #7 from janis at gcc dot gnu dot org 2008-07-28 22:26 ---
Smaller testcase, in C:
int*
get_global()
{
static __thread int global;
return global;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36955
--- Comment #8 from pinskia at gcc dot gnu dot org 2008-07-28 22:29 ---
The difference is the saving/restoring of r30. r30 is not used at all as far
as I can tell.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from dodji at gcc dot gnu dot org 2008-07-28 22:40 ---
Ah okay. So what is the email address to send the translation fixes to ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36958
--- Comment #4 from paolo dot carlini at oracle dot com 2008-07-28 23:09
---
Thanks, fix forthcoming.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #9 from janis at gcc dot gnu dot org 2008-07-28 23:21 ---
The difference is in setting up r30 before branching to __tls_get_addr, which
probably uses r30.
--
janis at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from pinskia at gcc dot gnu dot org 2008-07-28 23:27
---
From http://sourceware.org/ml/binutils/2005-05/msg00391.html:
Also, the ld support doesn't allow registers other than r30 as a GOT pointer.
booo.
-- Pinski
--
pinskia at gcc dot gnu dot org changed:
--- Comment #5 from paolo at gcc dot gnu dot org 2008-07-28 23:29 ---
Subject: Bug 36949
Author: paolo
Date: Mon Jul 28 23:28:16 2008
New Revision: 138219
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=138219
Log:
2008-07-28 Paolo Carlini [EMAIL PROTECTED]
PR
--- Comment #6 from paolo dot carlini at oracle dot com 2008-07-28 23:30
---
Fixed.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Take:
static inline int *fromSlotB(void)
{
static int shuf_BZZZ = 1;
return shuf_BZZZ;
}
int main(void)
{
return (int)fromSlotB();
}
--- CUT ---
At -O2, fromSlotB is still being emitted even though it is unused.
It is being marked in cxx_callgraph_analyze_expr:
else if (DECL_CONTEXT
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||4.1.1 4.4.0
Known to work||3.4.0
Apologies if this is a duplicate: I searched existing reports and found tons
of hits on virtual inheritance and reference, but couldn't find anything
like this. The following program illustrates the problem:
struct Lower {
const int ref;
Lower(const int ref) : ref(ref) {
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-07-29 00:01 ---
i = 0;
upper.D.2127.ref = i;
upper.D.2125._vptr$Middle = _ZTV5Upper + 12;
return *((struct Lower *) upper + (long unsigned int) *(int *)
_ZTV5Upper)-ref;
This works on the trunk correctly.
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-07-29 00:02 ---
Likewise for 4.3.0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36960
--- Comment #2 from jason at gcc dot gnu dot org 2008-07-29 00:06 ---
Subject: Bug 36943
Author: jason
Date: Tue Jul 29 00:06:08 2008
New Revision: 138221
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=138221
Log:
PR c++/36943
* decl.c (reshape_init_r): Allow
--- Comment #3 from jason at gcc dot gnu dot org 2008-07-29 00:07 ---
fixed, thanks.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from amodra at bigpond dot net dot au 2008-07-29 00:20
---
When -fPIC, r30 needs to be set to point into the .got2 section for the
function, so that r30 is valid for the __tls_get_addr plt call stub. Note that
this is a different GOT pointer than that used by @[EMAIL
--- Comment #12 from amodra at bigpond dot net dot au 2008-07-29 00:37
---
So, the easy fix for this bug is (totally untested, not even compiled)
Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c
enum A{a};
enum B{b};
class bottom {};
templatetypename E class attr {
public: E v;
operator E() { return v;}
};
templatetemplatetypename class node, typename attr, typename next
class attrNode : public nodeattr, public next {};
templatetemplatetypename class node
class list1 :
--- Comment #1 from igodard at pacbell dot net 2008-07-29 00:52 ---
Oops - sorry, posted wrong test case:
enum A{a};
enum B{b};
enum C{c};
enum D{d};
class bottom {};
templatetypename E class attr {
public: E v;
operator E() { return v;}
};
templatetemplatetypename class
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-07-29 00:53 ---
A x3 = attA(foo);
foo is a class.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36961
--- Comment #3 from igodard at pacbell dot net 2008-07-29 00:54 ---
p.s. Comeau likes the (correct, second) test case.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36961
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-07-29 01:01 ---
The error is correct as the type of v2 is foo so it cannot figure out the rest
of the template agruments from that type.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #13 from amodra at bigpond dot net dot au 2008-07-29 01:04
---
Blah, of course that's the wrong place to add the use_reg. Needs to be a few
lines lower. I guess I may as well take this bug and go thru a boot/regress
cycle.
--
amodra at bigpond dot net dot au changed:
--- Comment #5 from igodard at pacbell dot net 2008-07-29 01:07 ---
Please confirm that it is an error with your associates.
First, Comeau likes it.
Second, other template functions have no trouble identifying a template base
class given a derived class. What is different about this
--- Comment #3 from joseph at codesourcery dot com 2008-07-29 02:02 ---
Subject: Re: typos in french translation.
On Mon, 28 Jul 2008, dodji at gcc dot gnu dot org wrote:
Ah okay. So what is the email address to send the translation fixes to ?
See the Language-Team entry in the .po
--- Comment #6 from igodard at pacbell dot net 2008-07-29 02:32 ---
FWIW, Visual Studio has been reported to me as accepting the test case too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36961
78 matches
Mail list logo
