On Sun, 22 Apr 2007, Andrew Pinski wrote:
On 4/22/07, Andrew Pinski [EMAIL PROTECTED] wrote:
I think it was just by accident that the libfuncs would fit in
phi_node+3 operand slot. Also I think extra_order_size_table needs to
be relooked at after my phi_node and the gimple_stmt patches as
On Sun, 2007-04-22 at 17:32 -0700, Mark Mitchell wrote:
Steve Ellcey wrote:
It came up in a few side conversations. As I understand it, RMS has
decreed that the -On optimizations shall be architecture independent.
That said, there are generic optimizations which really only apply
to a
Hi there
I'd like to offer to help with Gnu Fortran development. Please would
you let me know in what areas volunteer help is needed, and I can
then tell you which areas fit in with my expertise. I like working on
apple macs, and I think I know them fairly well, but also have a
couple of
(In fact, there's nothing inherent in even using the same algorithms on
all processors; I can well imagine that the best register allocation
algorithms for x86 and Itanium might be entirely different. I'm in no
way trying to encourage an entire set of per-achitecture optimization
passes;
Richard Earnshaw wrote:
I think it would be nicer if this could be done in a MI way by examining
certain target properties. For example, the generic framework might say
something like: 'if there's more than N gp registers, enable opt_foo at
-O2 or above'.
Yes, I agree; wherever that
tree_io
.o
+===GNAT BUG DETECTED==+
| 4.3.0 20070423 (experimental) (i686-pc-cygwin) GCC error:|
| in set_curr_insn_source_location, at cfglayout.c:284 |
| Error detected around /usr/local/src/trunk/gcc/gcc/ada
-Wstrict-prototypes
-Wmissing-prototypes -fno-common -gnatpg -gnata -I- -I../rts -I. -I/usr/loc
al/src/trunk/gcc/gcc/ada /usr/local/src/trunk/gcc/gcc/ada/tree_io.adb -o tree_io
.o
+===GNAT BUG DETECTED==+
| 4.3.0 20070423 (experimental) (i686
I've promised to make more thorough and accurate comparison of
df-branch and mainline on last merge point to the branch. The
df-branch compiler does not include sunday's Steven's patch which uses
a separate obstack for df bitmaps. It does not change code but it can
speedup the df-branch
On 4/23/07, Vladimir Makarov [EMAIL PROTECTED] wrote:
...
To improve the scores I'd recommend to pay attention to big
degradation in SPEC score:
9% perlbmk degradation on Pentium4
3% fma3d degradation on Core2
3% eon and art degradation on Itanium
3% gap and wupwise degradation on PPC64.
Jim Wilson wrote:
Kenneth Hoste wrote:
I'm not sure what 'tests' mean here... Are test cases being extracted
from the SPEC CPU2006 sources? Or are you refering to the validity tests
of the SPEC framework itself (to check whether the output generated by
some binary conforms with their
Tim Prince wrote:
[EMAIL PROTECTED] wrote:
Where is gstdint.h ? Does it acctually exist ?
libdecnumber seems to use it.
decimal32|64|128.h's include decNumber.h which includes deccontext.h
which includes gstdint.h
When you configure libdecnumber (e.g. by running top-level gcc
configure),
On 4/23/07, Seongbae Park [EMAIL PROTECTED] wrote:
As for the perlbmk slowdown on P4.
my initial guess is that it might be due to cross-jumping or block ordering
- those are things I noticed the dataflow branch generates slightly
different code
than mainline.
I didn't try to narrow down where
On Sun, Apr 22, 2007 at 04:39:23PM -0700, Joe Buck wrote:
On Sun, 2007-04-22 at 14:44 +0200, Richard Guenther wrote:
At work we use -O3 since it gives 5% performance gain against -O2.
profile-feedback has many flags and there is no overview of it in the
doc IIRC. Who will use it except
On Mon, 23 Apr 2007, Mark Mitchell wrote:
I'm certainly not trying to suggest that we run SPEC on every
architecture, and then make -O2 be the set of optimization options that
happens to do best there, however bizarre.
Why not? Is your objection because SPEC doesn't reflect real-world apps
On Mon, 23 Apr 2007, Mark Mitchell wrote:
I'm certainly not trying to suggest that we run SPEC on every
architecture, and then make -O2 be the set of optimization options that
happens to do best there, however bizarre.
On Mon, Apr 23, 2007 at 01:21:20PM -0400, Kaveh R. GHAZI wrote:
Why
Kaveh R. GHAZI wrote:
On Mon, 23 Apr 2007, Mark Mitchell wrote:
I'm certainly not trying to suggest that we run SPEC on every
architecture, and then make -O2 be the set of optimization options that
happens to do best there, however bizarre.
Why not? Is your objection because SPEC doesn't
H. J. Lu [EMAIL PROTECTED] wrote on 23/04/2007 01:34:39:
On Mon, Apr 23, 2007 at 12:55:26AM +0300, Dorit Nuzman wrote:
H. J. Lu [EMAIL PROTECTED] wrote on 23/04/2007 00:29:16:
On Sun, Apr 22, 2007 at 11:14:20PM +0300, Dorit Nuzman wrote:
H. J. Lu [EMAIL PROTECTED] wrote on 20/04/2007
Mark Mitchell wrote on 04/23/07 13:56:
So, I think there's a middle ground between exactly the same passes on
all targets and use Acovea for every CPU to pick what -O2 means.
Using Acovea to reveal some of the suprising, but beneficial results,
seems like a fine idea, though.
I'm hoping to
Citeren Kaveh R. GHAZI [EMAIL PROTECTED]:
On Mon, 23 Apr 2007, Mark Mitchell wrote:
I'm certainly not trying to suggest that we run SPEC on every
architecture, and then make -O2 be the set of optimization options that
happens to do best there, however bizarre.
Why not? Is your objection
On 23 April 2007 19:07, Diego Novillo wrote:
Mark Mitchell wrote on 04/23/07 13:56:
So, I think there's a middle ground between exactly the same passes on
all targets and use Acovea for every CPU to pick what -O2 means.
Using Acovea to reveal some of the suprising, but beneficial results,
Vladimir Makarov wrote:
I've promised to make more thorough and accurate comparison of
df-branch and mainline on last merge point to the branch. The
df-branch compiler does not include sunday's Steven's patch which uses
a separate obstack for df bitmaps. It does not change code but it can
Citeren Diego Novillo [EMAIL PROTECTED]:
Mark Mitchell wrote on 04/23/07 13:56:
So, I think there's a middle ground between exactly the same passes on
all targets and use Acovea for every CPU to pick what -O2 means.
Using Acovea to reveal some of the suprising, but beneficial results,
seems
Dave Korn wrote on 04/23/07 14:26:
Has any of the Acovea research demonstrated whether there actually is any
such thing as a good default set of flags in all cases? If the results
Not Acovea itself. The research I'm talking about involves a compiler
whose pipeline can be modified and
Citeren Dave Korn [EMAIL PROTECTED]:
On 23 April 2007 19:07, Diego Novillo wrote:
Mark Mitchell wrote on 04/23/07 13:56:
So, I think there's a middle ground between exactly the same passes on
all targets and use Acovea for every CPU to pick what -O2 means.
Using Acovea to reveal some of the
[EMAIL PROTECTED] wrote on 04/23/07 14:37:
Currently, the -On flags set/unset 60 flags, which yields 2^60 conbinations.
If you also kind the passes not controlled by a flag, but decided upon
depending on the optimization level, that adds another, virtual flag
(i.e. using -O1, -O2, -O3 or
On Mon, Apr 23, 2007 at 09:05:05PM +0300, Dorit Nuzman wrote:
H. J. Lu [EMAIL PROTECTED] wrote on 23/04/2007 01:34:39:
On Mon, Apr 23, 2007 at 12:55:26AM +0300, Dorit Nuzman wrote:
H. J. Lu [EMAIL PROTECTED] wrote on 23/04/2007 00:29:16:
On Sun, Apr 22, 2007 at 11:14:20PM +0300,
[EMAIL PROTECTED] wrote on 04/23/07 14:40:
Any references?
Yes, at the last HiPEAC conference Grigori Fursin presented their
interactive compilation interface, which could be used for this.
http://gcc-ici.sourceforge.net/
Ben Elliston had also experimented with a framework to allow GCC to
On Mon, 2007-04-23 at 10:56 -0700, Mark Mitchell wrote:
Kaveh R. GHAZI wrote:
On Mon, 23 Apr 2007, Mark Mitchell wrote:
I'm certainly not trying to suggest that we run SPEC on every
architecture, and then make -O2 be the set of optimization options that
happens to do best there,
On 23 Apr 2007, at 20:43, Diego Novillo wrote:
[EMAIL PROTECTED] wrote on 04/23/07 14:37:
Currently, the -On flags set/unset 60 flags, which yields 2^60 conbinations.
If you also kind the passes not controlled by a flag, but decided upon
depending on the optimization level, that adds another,
On Mon, Apr 23, 2007 at 09:49:04AM -0700, Steve Ellcey wrote:
Jim Wilson wrote:
Kenneth Hoste wrote:
I'm not sure what 'tests' mean here... Are test cases being extracted
from the SPEC CPU2006 sources? Or are you refering to the validity tests
of the SPEC framework itself (to check
This is a know problem until the Ada people fix their frontend.
Could you elaborate? What's known problem exactly?
I suppose the upfront notice was not sent.
Indeed, and the timing is quite unfortunate since the Ada compiler was
independently broken yesterday too and is moreover plagued by
On Fri, Apr 20, 2007 at 01:07:14PM -0400, Aldy Hernandez wrote:
+ /* There can be 3 types of unary operations:
+
+ SYM = constant == GSS_ASSIGN_UNARY_REG
+ SYM = SYM2 == GSS_ASSIGN_UNARY_MEM
Um, ssa_name = ssa_name isn't a memory
+/* A
I am working on the cegcc project (http://cegcc.sourceforge.net), which
bundles a bunch of the GNU development tools to produce a
cross-development environment for ARM devices running Windows CE. The
development hosts supported are Linux and Cygwin.
Gcov normally puts the files where it writes
+/* A sequences of gimple statements. */
+#define GS_SEQP_FIRST(S) (S)-first
+#define GS_SEQP_LAST(S)(S)-last
+#define GS_SEQ_FIRST(S)(S).first
+#define GS_SEQ_LAST(S) (S).last
Why do you have both of these?
Most places in the gimplifier we will
I presume that this:
-I../../trunk/gcc/../libdecnumber/bid -I../libdecnumber
../../trunk/gcc/gimplify.c -o gimplify.o
../../trunk/gcc/gimplify.c: In function 'create_tmp_var_name':
../../trunk/gcc/gimplify.c:431: internal compiler error: in
set_curr_insn_source_location, at
On 4/23/07, Paul Richard Thomas [EMAIL PROTECTED] wrote:
on x86_ia64/fc5 is not a coincidence?
More over, there were a lot of targets by this patch because they
would call insn_locators_initialize when generating the thunks (x86
did not because it uses text based thunks and not RTL based
H. J. Lu [EMAIL PROTECTED] wrote on 23/04/2007 21:56:37:
...
so this looks like a vec_unpacku_hi_v4si (or _lo?), i.e. what
is
now
modeled as follows in sse.md:
(define_expand vec_unpacku_hi_v4si
[(match_operand:V2DI 0 register_operand )
On Mon, Apr 23, 2007 at 04:30:40PM -0400, Aldy Hernandez wrote:
I figured
it'd be better than doing GS_SEQP_FIRST(non_pointer), but I can if you
prefer.
I think I would, though without the P.
r~
J.C. Pizarro wrote:
Your idea with JavaScript, CSS, XSLT, .. is very good! :)
Thanks you - but ideas are cheap. Turned a vague idea into
something useful is a different matter
--
--Per Bothner
[EMAIL PROTECTED] http://per.bothner.com/
Since the change listed below, bootstrap on powerpc is broken when you
configure for both powerpc-linux and powerpc64-linux:
2007-04-04 Jakub Jelinek [EMAIL PROTECTED]
* libgomp.h (gomp_cpu_affinity, gomp_cpu_affinity_len): New extern
decls.
The error I get is:
Snapshot gcc-4.1-20070423 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20070423/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.1 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Hi
I am wondering how gcc handles producing debug information for
automatic variables that do not reside inthe stack.For example when
say register allocation decides to assign a particular register to a
variable or say it decides that the value is a constant. Can some
one point me to the
)
movdqa %xmm3, y+80(%rip)
movdqa %xmm1, y+96(%rip)
movdqa %xmm0, y+112(%rip)
ret
.size foo, .-foo
.ident GCC: (GNU) 4.3.0 20070423 (experimental) [trunk revision
124056]
.section.note.GNU-stack,,@progbits
I figured
it'd be better than doing GS_SEQP_FIRST(non_pointer), but I can if you
prefer.
I think I would, though without the P.
Ok, everything fixed, except I haven't added the sequence iterators yet.
I am committing the patch below to the gimple-tuples-branch.
Thanks again.
On 4/23/07, Paul Richard Thomas [EMAIL PROTECTED] wrote:
on x86_ia64/fc5 is not a coincidence?
More over, there were a lot of targets by this patch because they
would call insn_locators_initialize when generating the thunks (x86
did not because it uses text based thunks and not RTL based
It happens! It also meant that I got to bed early:)
Thanks
Paul
On 4/24/07, Jan Hubicka [EMAIL PROTECTED] wrote:
On 4/23/07, Paul Richard Thomas [EMAIL PROTECTED] wrote:
on x86_ia64/fc5 is not a coincidence?
More over, there were a lot of targets by this patch because they
would call
[EMAIL PROTECTED] wrote:
Tim Prince wrote:
[EMAIL PROTECTED] wrote:
Where is gstdint.h ? Does it acctually exist ?
libdecnumber seems to use it.
decimal32|64|128.h's include decNumber.h which includes deccontext.h
which includes gstdint.h
When you configure libdecnumber (e.g. by running
--- Comment #5 from eduardo dot iniesta at aquiline dot es 2007-04-23
07:53 ---
(In reply to comment #4)
Please post the output of running gcj -C -v Fail.java
Thanks.
The output of running gcj -C -v Fail.java is:
$ gcj -C -v Fail.java salida_compila.txt
Usando especificaciones
--- Comment #3 from chrbr at gcc dot gnu dot org 2007-04-23 07:59 ---
Hi Kaj,
The same problem seems to transpire from the movsf_ie pattern for the sh2a-fpu
that also have 32 bit memory instructions. So your fix also applies there.
Note that traditional sh memory move instructions can
I get the following segfault with current gcc 4.3. This was introduced
between 20070330-r123378 (works) and 20070417-r123941 (segfault). This
is related to the use of anonymous namespace.
I believe it was caused by:
2007-04-16 Seongbae Park [EMAIL PROTECTED]
PR c++/29365
*
--- Comment #6 from ghazi at gcc dot gnu dot org 2007-04-23 08:52 ---
Subject: Bug 31616
Author: ghazi
Date: Mon Apr 23 08:52:24 2007
New Revision: 124059
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124059
Log:
PR fortran/31616
* gfortran.dg/open_errors.f90:
--- Comment #4 from kkojima at gcc dot gnu dot org 2007-04-23 09:53 ---
The same problem seems to transpire from the movsf_ie pattern for the sh2a-fpu
that also have 32 bit memory instructions. So your fix also applies there.
Ah, thanks! I'll add movsf_ie part when I return to this
--- Comment #9 from anirkko at insel dot ch 2007-04-23 11:35 ---
(In reply to comment #8)
The bootstrap works fine with all flags equal to '-O2'
Great, thanks for the confirmation.
Still worrysome, because somewhere in the installation instructions, it is
recommended to
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2007-04-23 11:55
---
It is in the main directory, file FAQ, section Optimizing the compiler
itself:
If you want to test a particular optimization option, it's useful to
try bootstrapping the compiler with that
--- Comment #6 from keinstein_junior at gmx dot net 2007-04-23 12:08
---
I tried to add a new testcase which shows the error with my gfortran-4.2. But
got an error.
It's located at http://rcswww.urz.tu-dresden.de/~s7935097/src-differror2.tgz
now.
FYI alloys.mod depends on the other
--- Comment #2 from krebbel at gcc dot gnu dot org 2007-04-23 12:21 ---
In your example the memset function is called with -1 as length argument. When
GCC tries to expand this as a builtin function an assertion in the s390 back
end function s390_expand_setmem is triggered. Although an
--- Comment #10 from rguenth at gcc dot gnu dot org 2007-04-23 12:47
---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pcarlini at suse dot de 2007-04-23 13:35 ---
(In reply to comment #5)
It is OK with me.
Ok, excellent. For 4_2-branch we have a nuisance, in that the original testcase
involves -Wconversion which in that branch does nothing in C++. Thus I tested
on ia64-linux the
--- Comment #7 from pcarlini at suse dot de 2007-04-23 13:36 ---
Created an attachment (id=13430)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13430action=view)
Patch for 4_2-branch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31638
--- Comment #3 from uweigand at gcc dot gnu dot org 2007-04-23 14:51
---
I don't think the patch is correct; according to the C standard,
the third argument of memset is of type size_t, which must be
an *unsigned* type, so it cannot in fact be negative.
What apparently happens is that
In cp/decl.c there is this code
warning (OPT_Wshadow, shadowing %s function %q#D,
DECL_BUILT_IN (olddecl) ? built-in : library,
olddecl);
The strings substituted for the first %s are not available for translation, so
this can not be
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-04-23 15:07 ---
http://gcc.gnu.org/ml/gcc-patches/2007-04/msg01191.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31663
In
http://gcc.gnu.org/ml/gcc-testresults/2007-04/msg01156.html
there is
FAIL: g++.old-deja/g++.other/vbase5.C execution test
--
Summary: [4.3 regression]: g++.old-deja/g++.other/vbase5.C
execution test
Product: gcc
Version: 4.3.0
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-04-23 15:26 ---
Confirmed, I also see this.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from tromey at gcc dot gnu dot org 2007-04-23 15:26 ---
Subject: Bug 30468
Author: tromey
Date: Mon Apr 23 15:26:21 2007
New Revision: 124067
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124067
Log:
PR preprocessor/30468:
* mkdeps.c (apply_vpath):
--- Comment #8 from tromey at gcc dot gnu dot org 2007-04-23 15:27 ---
Subject: Bug 30468
Author: tromey
Date: Mon Apr 23 15:26:51 2007
New Revision: 124068
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124068
Log:
PR preprocessor/30468:
* mkdeps.c (apply_vpath):
SSE4.1 has pmovzx and pmovsx. For code like:
[EMAIL PROTECTED] vect]$ cat pmovzxbw.c
typedef unsigned char vec_t;
typedef unsigned short vecx_t;
extern __attribute__((aligned(16))) vec_t x [64];
extern __attribute__((aligned(16))) vecx_t y [64];
void
foo ()
{
int i;
for (i = 0; i 64; i++)
--- Comment #9 from tromey at gcc dot gnu dot org 2007-04-23 15:27 ---
Fixed on 4.1 and 4.2 branches.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from vaclav dot kocian at wo dot cz 2007-04-23 15:33 ---
My RAM is 512MB. Well, the newer version of gcc says :
You need to increase the datasize limit to at least 70 (and set
kern.maxdsiz=734003200 in /boot/loader.conf) to build with Java
support.
I do not
--- Comment #8 from pault at gcc dot gnu dot org 2007-04-23 16:14 ---
Subject: Bug 31620
Author: pault
Date: Mon Apr 23 16:13:48 2007
New Revision: 124069
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124069
Log:
2007-04-23 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #3 from pault at gcc dot gnu dot org 2007-04-23 16:14 ---
Subject: Bug 31630
Author: pault
Date: Mon Apr 23 16:13:48 2007
New Revision: 124069
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124069
Log:
2007-04-23 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #2 from theodore dot papadopoulo at sophia dot inria dot fr
2007-04-23 16:46 ---
(From update of attachment 13378)
Slightly simplified the testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31598
--- Comment #2 from spark at gcc dot gnu dot org 2007-04-23 16:53 ---
My patch (which is still waiting for a review) should fix this.
--
spark at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from theodore dot papadopoulo at sophia dot inria dot fr
2007-04-23 17:01 ---
Sorry to have added you without asking Jakub, but it looks like you are one of
the person that deals with OpenMP and this bug seems to have been unnoticed
up to now...
It seems that this
--- Comment #5 from janis at gcc dot gnu dot org 2007-04-23 17:02 ---
A regression hunt on powerc-linux using the submitter's testcase identified the
following patch:
http://gcc.gnu.org/viewcvs?view=revrev=64815
r64815 | nathan | 2003-03-24 19:47:17 + (Mon, 24 Mar 2003)
--- Comment #3 from janis at gcc dot gnu dot org 2007-04-23 17:06 ---
A regression hunt on powerpc-linux identified the following patch:
http://gcc.gnu.org/viewcvs?view=revrev=69715
r69715 | mmitchel | 2003-07-23 18:44:43 + (Wed, 23 Jul 2003)
--
janis at gcc dot gnu
--- Comment #3 from janis at gcc dot gnu dot org 2007-04-23 17:19 ---
A regression hunt on powerpc-linux identified the following patch:
http://gcc.gnu.org/viewcvs?view=revrev=116311
r116311 | jason | 2006-08-21 13:54:57 -0700 (Mon, 21 Aug 2006)
--
janis at gcc dot gnu dot
--- Comment #6 from tromey at gcc dot gnu dot org 2007-04-23 17:24 ---
Ok. You are running a version of gcj 4.3 from *before* the gcj-eclipse
merge. So, this is correctly marked as a duplicate.
If you update and rebuild, and follow the new instructions vis a vis ecj1,
you will get a
--- Comment #4 from numerical dot simulation at web dot de 2007-04-23
17:24 ---
Sorry, the link was wrong, must be
http://groups.google.de/group/comp.lang.c++.moderated/browse_thread/thread/8c3b8a84ed78b003/4d9603171894a75d?hl=de#4d9603171894a75d
--
--- Comment #7 from janis at gcc dot gnu dot org 2007-04-23 17:27 ---
A regression hunt identified the tree-ssa merge to mainline.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31411
--- Comment #9 from pault at gcc dot gnu dot org 2007-04-23 17:52 ---
Fixed on trunk
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pault at gcc dot gnu dot org 2007-04-23 17:52 ---
Fixed on trunk
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
Reported by Arjan van Dijk,
http://gcc.gnu.org/ml/fortran/2007-04/msg00367.html
gfortran rejects the following code with the error:
By-value argument at (1) is not allowed in this context
This is because the following check is matched: resolve.c,
resolve_actual_arglist():
/*
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu dot
|
Ada compiler, GNAT, blows up during compilation of the code segment below with
an unhandled exception error message raised RTSIFND.RE_NOT_AVAILABLE :
rts.find.adb:210
package Abstract_Base is
pragma Pure;
type Base_Type is abstract tagged limited private;
procedure Update (This :
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
#include stdio.h
typedef struct{
char data[261];
int n;
} packet;
int main(int argc, char *argv[]){
packet p;
//It should print packet=265... it prints packet=268
printf(packet = %d\n, sizeof(packet));
//It should print p=265... it prints p=268
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-04-23 19:32 ---
Learn about alignment when doing struct layout. Basically you want to use the
attribute packed to get the sizes you want.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #6 from amylaar at gcc dot gnu dot org 2007-04-23 19:37 ---
(In reply to comment #5)
Fixed.
I also see mayalias-2 failing with gcc 4.2 on arc at
-O3 -fomit-frame-pointer.
Life analysis finds a 'clever' way to initialize the pointer p
by copying the frame pointer and then
The following code compiles in all the gcc versions I tested (4.0.1, 4.1.1,
4.1.2):
templateint i void doit() {
i = 0;
}
templateconst int i class X {
public:
void foo() {
doiti();
}
};
int i;
Xi x;
int main(int argc, char **argv) {
x.foo();
}
Note that if i is
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-04-23 20:14 ---
Confirmed, not a regression as far as I can tell.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
This feature is used classic Fortran 77 libraries such as Starpac, as
mentioned in comp.lang.fortran on 23-Apr-2007 .
c:\fortran type d1mach.f90
function d1mach(i)
implicit none
double precision d1mach,dmach(5)
integer i,large(4),small(4)
equivalence ( dmach(1), small(1) )
equivalence ( dmach(2),
--- Comment #8 from tkoenig at gcc dot gnu dot org 2007-04-23 20:44 ---
Subject: Bug 31618
Author: tkoenig
Date: Mon Apr 23 20:43:54 2007
New Revision: 124079
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124079
Log:
2007-04-23 Thomas Koenig [EMAIL PROTECTED]
PR
--- Comment #9 from tkoenig at gcc dot gnu dot org 2007-04-23 20:46 ---
Fixed on trunk.
Maybe we should backport this once 4.2.1 is open.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from brooks at gcc dot gnu dot org 2007-04-23 20:48 ---
*** Bug 31672 has been marked as a duplicate of this bug. ***
--
brooks at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from brooks at gcc dot gnu dot org 2007-04-23 20:48 ---
Thanks for reporting this -- this is a rather nicer testcase than the one we
had for this already.
I've also changed the title of PR #29786 to make it easier to find.
*** This bug has been marked as a duplicate of
--- Comment #9 from brooks at gcc dot gnu dot org 2007-04-23 20:49 ---
I'm changing the name of this bug to make it a lot easier to find, now that we
know what the actual problem is.
Also, PR #31672 contains an excellent testcase for this, which I'll quote here:
--- Comment #17 from arcangelpip at hotmail dot com 2007-04-23 20:51
---
Yup, that did it. Building the cross compiler with that patch fixed the test
case ICE and the one I kept getting from gettext.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29826
--
brooks at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P5 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29786
1 - 100 of 129 matches
Mail list logo
