--- Comment #8 from jv244 at cam dot ac dot uk 2009-08-11 07:10 ---
Further reduced testcase
MODULE deriv_class
INTEGER, PARAMETER :: n = 3
TYPE func
REAL :: value, x(n), xx(n*(n+1)/2)
END TYPE func
INTERFACE value
MODULE PROCEDURE value_array
END INTERFACE
INTERFA
--- Comment #3 from krebbel at gcc dot gnu dot org 2009-08-11 07:56 ---
The same happens when bootstrapping on s390x while building libdecnumber. Here
is a reduced testcase:
typedef struct
{
unsigned char bits;
unsigned short int lsu[1];
} decNumber;
void
decCompareOp (decNumber *
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-08-11 08:35 ---
Well, the issue is that even LIM doesn't move the load because loop header
copying is not run at -Os which usually makes loop analysis hard.
At -O2 -fno-tree-pre it works, but at -Os it doesn't.
We should be better
--- Comment #4 from hp at gcc dot gnu dot org 2009-08-11 09:26 ---
(In reply to comment #3)
> The same happens when bootstrapping on s390x while building libdecnumber. Here
> is a reduced testcase:
At -O1, the simplified test-case exposes the bug for cris-elf too.
FWIW, I guess you must
--- Comment #3 from mexas at bristol dot ac dot uk 2009-08-11 11:14 ---
Some very basic analysis.
gcc43 builds on alpha, but not on ia64,
so I was trying to spot the difference.
# pwd
/usr/ports/lang/gcc43
# grep -C3 crtfastmath ./work/build/gcc/Makefile
# List of extra object files th
We do not complete structs during type merging nor do we consider types which
just differ in completeness as equal.
t1.c:
struct X;
struct Y
{
struct X *p;
int i;
};
void foo (struct Y *p)
{
p->i = 1;
}
t2.c:
/* struct X is complete in this TU, this causes us to not merge Y and
thus assi
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-08-11 11:17 ---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned
--- Comment #8 from guerby at gcc dot gnu dot org 2009-08-11 11:40 ---
Subject: Bug 40788
Author: guerby
Date: Tue Aug 11 11:39:43 2009
New Revision: 150648
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150648
Log:
2009-08-11 Richard Guenther
PR bootstrap/40788
--- Comment #9 from laurent at guerby dot net 2009-08-11 11:43 ---
Fixed.
--
laurent at guerby dot net changed:
What|Removed |Added
Status|NEW
--- Comment #9 from jv244 at cam dot ac dot uk 2009-08-11 11:56 ---
(In reply to comment #8)
> Further reduced testcase
looking a this more, this testcase really looks different from what Paul
suggested in comment #6 (i.e. there is no pointer to the component of an array
of derived type
struct X {
int i;
int j;
};
int foo(struct X *p, struct X *q)
{
p->j = 1;
q->i = 0;
return p->j;
}
extern void abort (void);
int main()
{
struct X x;
if (foo (&x, (struct X *)&x.j) != 0)
abort ();
return 0;
}
is miscompiled at -O1.
--
Summary: RTL alias-oracle
--- Comment #9 from mahatma at eu dot by 2009-08-11 12:49 ---
Simplest way to save Bug 32893 solution: replace MAX_STACK_ALIGNMENT by
STACK_BOUNDARY in vect_can_force_dr_alignment_p (tree-vectorizer.c / ...). No
error more.
--
mahatma at eu dot by changed:
What|Remove
--- Comment #10 from mahatma at eu dot by 2009-08-11 13:00 ---
Created an attachment (id=18340)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18340&action=view)
patch
For gcc 4.4.1. Moved to tree-vect-data-refs.c in cvs.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40985
--- Comment #9 from eric dot weddington at atmel dot com 2009-08-11 13:29
---
Closing old bug as WONTFIX. Open up a new bug if it is still a problem.
--
eric dot weddington at atmel dot com changed:
What|Removed |Added
--- Comment #12 from jwakely dot gcc at gmail dot com 2009-08-11 14:16
---
revised 'Explicit Virtual Function Overrides' paper:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2928.htm
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31397
--- Comment #10 from jwakely dot gcc at gmail dot com 2009-08-11 14:24
---
as with bug 31937, there is overlap between this enhancement and the 'Explicit
Virtual Function Overrides' paper,
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2928.htm
the attributes proposed in that
--
m_albert137 at yahoo dot com changed:
What|Removed |Added
Severity|normal |major
Component|libstdc++ |c++
http://gcc.
--- Comment #31 from giffordj at la dot twcbc dot com 2009-08-11 15:09
---
http://sourceware.org/ml/binutils/2009-08/msg00163.html appears to have fixed
this issue. See http://sourceware.org/bugzilla/show_bug.cgi?id=10474 for
details.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-08-11 15:24 ---
Disabling vectorization fixes the problem (-fno-tree-vectorize), happens on
trunk as well. 4.3 doesn't like the testcase, so it's not yet a regression.
--
rguenth at gcc dot gnu dot org changed:
What
http://gcc.gnu.org/ml/fortran/2009-08/msg00095.html
Excess errors:
/usr/home/sgk/gcc/gcc4x/gcc/testsuite/gfortran.dg/compiler-directive_1.f90:33:
Error: Mismatch in the procedure pointer assignment at (1): mismatch in the
calling convention
/usr/home/sgk/gcc/gcc4x/gcc/testsuite/gfortran.dg/compile
--- Comment #8 from uros at gcc dot gnu dot org 2009-08-11 17:06 ---
Subject: Bug 8603
Author: uros
Date: Tue Aug 11 17:05:38 2009
New Revision: 150654
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150654
Log:
PR target/8603
* config/alpha/alpha.md (addsi3): Rem
--- Comment #23 from sje at cup dot hp dot com 2009-08-11 17:18 ---
I don't have complete results because my builds failed due to a bad libstdc++
checkin (that has been fixed) but the C and Fortran parts all looked good.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40952
Hello,
Following code (written just for fun) leads to:
Program received signal SIGSEGV, Segmentation fault.
main () at main-general.cpp:95
95 printf("%d\n", x_reg);
BTW, there is warning when using ecx, eax, edx.
should there be any warning for esp?
gcc
svn://gcc.gnu.org/svn/gcc/b
gcc.dg/tortore/builtin-math-5.c
/* Check for overflow/underflow. */
TESTIT (cexp, 1e20);
TESTIT (cexp, -1e20);
produces
foof (__builtin_cexpf (__complex__ (1.0002004087734272e+20, 0.0)));
foo (__builtin_cexp (__complex__ (1.0e+20, 0.0)));
fool (__builtin_cexpl (__complex__ (1.0e
--- Comment #1 from dodji at gcc dot gnu dot org 2009-08-11 18:40 ---
Subject: Bug 40990
Author: dodji
Date: Tue Aug 11 18:39:54 2009
New Revision: 150659
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150659
Log:
Fix PR debug/40990
PR debug/40990
* lang.c (put_
--- Comment #1 from ubizjak at gmail dot com 2009-08-11 18:41 ---
(In reply to comment #0)
> Following code (written just for fun) leads to:
>
> Program received signal SIGSEGV, Segmentation fault.
> main () at main-general.cpp:95
> 95 printf("%d\n", x_reg);
>
>
> BTW, t
--- Comment #1 from burnus at gcc dot gnu dot org 2009-08-11 19:06 ---
The following patch is needed to initialize the variables; however, it does not
solve the actual problem - here, we only make the checks tighter.
For some reason, the LHS seems to be 0 all the time while the RHS gets
--- Comment #2 from sergey dot senozhatsky at gmail dot com 2009-08-11
19:18 ---
Subject: Re: SIGSEGV with register asm esp
On (08/11/09 18:41), ubizjak at gmail dot com wrote:
> No. You should be able to shoot yourself in the foot without warning.
>
> IOW, you are changing stack poi
--- Comment #6 from janus at gcc dot gnu dot org 2009-08-11 20:08 ---
Subject: Bug 41022
Author: janus
Date: Tue Aug 11 20:08:35 2009
New Revision: 150665
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150665
Log:
2009-08-11 Janus Weil
PR fortran/41022
* tran
--- Comment #7 from janus at gcc dot gnu dot org 2009-08-11 20:15 ---
Fixed with r150665. Thanks for the report.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #5 from afoglia at gmail dot com 2009-08-11 20:17 ---
(In reply to comment #4)
> Disabling vectorization fixes the problem (-fno-tree-vectorize), happens on
> trunk as well. 4.3 doesn't like the testcase, so it's not yet a regression.
>
4.3 may not like the test case, but
--- Comment #8 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-08-11 20:38 ---
Created an attachment (id=18341)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18341&action=view)
A patch for -freg-struct-return
Another patch that makes -freg-struct-return consistent.
--- Comment #9 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-08-11 20:40 ---
The Basic rule implemented in both patches is: when you have aggregate type,
you MUST NOT look at mode to infer parameter or return method. It is
unreliable.
--
http://gcc.gnu.org/bugzilla/
--- Comment #2 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-08-11 20:48 ---
Another inconsistency: struct { float f }; is returned in ST(0) in GCC and in
EAX on Windows. struct { double f }; is returned in ST(0) in GCC and in EDX:EAX
on Windows. See PR 41017 for more ex
--- Comment #24 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-08-11 21:01 ---
Another case when stack frame is spuriously generated:
/* -O2 -fomit-frame-pointer -mno-accumulate-outgoing-args */
void __attribute__((__noreturn__)) crash(__const__ char *, ...);
void F(in
--- Comment #6 from kkojima at gcc dot gnu dot org 2009-08-11 22:37 ---
Subject: Bug 41015
Author: kkojima
Date: Tue Aug 11 22:36:56 2009
New Revision: 150667
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150667
Log:
Backport from mainline:
2009-08-10 SUGIOKA T
--- Comment #7 from kkojima at gcc dot gnu dot org 2009-08-11 22:38 ---
Fixed.
--
kkojima at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
Consider:
#include
#include
int main()
{ std::printf("%d\n", std::cerr.flags() & std::ios_base::dec); }
In 27.3.1p5, the standard states:
After the object cerr is initialized, cerr.flags() & unitbuf is
nonzero. Its state is otherwise the same as required for
basic_
--- Comment #7 from jwakely dot gcc at gmail dot com 2009-08-11 23:02
---
This patch (and running autoreconf) fixes the problem, but I'm still trying to
work out the right changes to the linker script so that the new symbols are
versioned as GLIBCXX_3.4.13 not GLIBCXX_3.4
Index: src/Ma
The following code compiles ok with -DOK1 or -DOK2. The default case generate
the following error which seems wrong.
gmo2.cc: In member function 'int Packer::foo()':
gmo2.cc:17:29: error: request for member 'size' in 'Packer::var', which is of
non-class type 'const std::string&'
#include
templ
--- Comment #7 from bje at gcc dot gnu dot org 2009-08-12 01:42 ---
Confirmed, given that a test case is failing.
--
bje at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from spop at gcc dot gnu dot org 2009-08-12 03:29 ---
Subject: Bug 40980
Author: spop
Date: Wed Aug 12 03:29:35 2009
New Revision: 150674
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150674
Log:
Prepare expressions to be good phi arguments.
2009-08-11 Sebastia
The check for declarations that could, if reordered within a class, alter the
meaning of that class (and thus be ill-formed) is overly restrictive.
Specifically, it bans any declaration that might cause such an issue, while a
program is ill-formed only if the reordering would actually cause an ambi
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-08-12 06:15 ---
> because there is nothing to reorder, so the meaning of bar cannot possibly
> change.
But the rule is not designed that way IIRC. Even if it is too strict I think
that is the correct way of doing things.
--
h
--- Comment #2 from coppro at users dot sf dot net 2009-08-12 06:26 ---
[basic.scope.class]:
3) If reordering member declarations in a class yields an alternate valid
program under (1) and (2), the program is ill-formed, no diagnostic is
required.
Otherwise, the program is well-formed,
45 matches
Mail list logo
