--- Comment #7 from yast4ik at yahoo dot com 2009-02-22 08:01 ---
It is seems to me patch works. Thank you for quick solution.
--
yast4ik at yahoo dot com changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-02-22 09:24 ---
The micro branch is not part of the FSF SVN so this is not a bug here. Report
this to the developers of the micro branch.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
When testing a 64 bits compiler ACATS is clean but gnat.dg has one FAIL:
http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg02180.html
FAIL: gnat.dg/pack3.adb execution test
raised PROGRAM_ERROR : pack3.adb:29 explicit raise
pack3.adb test was introduced together with this patch:
2008-03-07
--- Comment #42 from hubicka at gcc dot gnu dot org 2009-02-22 11:21
---
Actual representation of constructor don't seem to be major problem here.
We seem to build _a lot_ (117MB) of CONVERT exprs just to call fold on it and
convert integer to proper type, so counting in INTEGER_CSTs
+++ This bug was initially created as a clone of Bug #38727 +++
The autogen program finds fixinclude test failures in miro :
# gmake -i check
gmake[2]: Entering directory `/usr/share/src/miro_build/fixincludes'
autogen -T ../../miro/fixincludes/check.tpl ../../miro/fixincludes/inclhack.def
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-02-22 12:18 ---
What is the miro branch?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39265
--- Comment #2 from rob1weld at aol dot com 2009-02-22 12:19 ---
(In reply to comment #1)
The micro branch is not part of the FSF SVN so this is not a bug here. Report
this to the developers of the micro branch.
It is not micro it is miro !
http://gcc.gnu.org/wiki/MIRO
svn co
--- Comment #2 from steven at gcc dot gnu dot org 2009-02-22 12:21 ---
creating MIRO (Mudflap Improved with Referent Objects) branch
Seb?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-02-22 12:23 ---
miro branch was created but never touched so invalid.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-02-22 12:23 ---
miro branch was created but never touched so invalid.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-02-22 12:24 ---
miro branch was created but never touched so invalid.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39262
--- Comment #3 from rob1weld at aol dot com 2009-02-22 12:51 ---
(In reply to comment #1)
Rob, did you ever read http://gcc.gnu.org/bugs.html#report ?
To be honest, I don't even know _what_ are you reporting here. There is no
point to post hundreds of lines from build logs, since
--- Comment #4 from rob1weld at aol dot com 2009-02-22 12:54 ---
http://gcc.gnu.org/wiki/MIRO
svn co svn://gcc.gnu.org/svn/gcc/branches/miro miro
Please read: http://gcc.gnu.org/svn.html#devbranches
The miro branch is listed under Active Development Branches.
Lets go with this
--- Comment #4 from steven at gcc dot gnu dot org 2009-02-22 12:56 ---
Did you ever read: http://gcc.gnu.org/svn.html#devbranches
The miro branch is listed under Active Development Branches.
Well, it doesn't look active to me.
Seb, please do something here (move to inactive, or
--- Comment #4 from rob1weld at aol dot com 2009-02-22 12:58 ---
(In reply to comment #3)
miro branch was created but never touched so invalid.
It is listed as an ADB, if it were to merge I wanted
to be sure it worked. I was not going to spend a lot
of time on it, just one run
--- Comment #5 from steven at gcc dot gnu dot org 2009-02-22 12:59 ---
Indeed.
But Rob, Pinski has a point: There really are better things to spend your time
on than building development branches. Such branches are often highly
experimental or very unstable, so bugs are not usually
--- Comment #10 from steven at gcc dot gnu dot org 2009-02-22 14:01 ---
Trees were refactored, and we currently have:
struct tree_base
{
ENUM_BITFIELD(tree_code) code : 16;
/* 48 bits for various bitfield flags */
union tree_ann_d *ann;
} /* So on a 64-bit host this is 128bits =
--- Comment #22 from steven at gcc dot gnu dot org 2009-02-22 14:15 ---
Last modified is long ago. Richi, you added it to the daily testers. How is
it doing there?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12392
--- Comment #10 from steven at gcc dot gnu dot org 2009-02-22 14:19 ---
What happened with the alloca patch? Looks like it was never committed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29442
I built gfortran 4.4 on a Sparc workstation running Debian Linux 5.0. I
attempted to compile the following program:
PROGRAM test
INTEGER, DIMENSION(8) :: count
CALL RANDOM_SEED(PUT=count)
END PROGRAM test
I got the message:
CALL RANDOM_SEED(PUT=count)
1
Error: Size of 'put'
--- Comment #11 from hubicka at gcc dot gnu dot org 2009-02-22 14:22
---
Created an attachment (id=17340)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17340action=view)
Dump of block structure
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37709
--- Comment #15 from steven at gcc dot gnu dot org 2009-02-22 14:23 ---
Re. Comment #14 -- Fixed on AIB?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23940
--- Comment #12 from hubicka at gcc dot gnu dot org 2009-02-22 14:23
---
Created an attachment (id=17341)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17341action=view)
Little dumping facility
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37709
--- Comment #7 from steven at gcc dot gnu dot org 2009-02-22 14:27 ---
Works for me on a machine limited to 512MB (tops at 300MB, which is
unfortunately a small footprint by GCC's current standard).
--
steven at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from steven at gcc dot gnu dot org 2009-02-22 14:32 ---
If it works with one debian version, but not another, isn't it something you
should report to debian as their problem, then? It is impossible to tell what
is going on without knowing/understanding the difference
--- Comment #4 from Jason dot A dot Wilkins at gmail dot com 2009-02-22
14:43 ---
(In reply to comment #3)
It is my understanding that constructors are not inherited so a derived class
really does not declare or define a copy constructor.
--
Jason dot A dot Wilkins at gmail dot com
--- Comment #13 from hubicka at gcc dot gnu dot org 2009-02-22 14:46
---
There are obviously giant trees of blocks that have all variables unused and no
statements in them coming from the early inliner. I am getting convinced we
can safely prune those even at -g3: user can not
--- Comment #51 from hubicka at ucw dot cz 2009-02-22 14:47 ---
Subject: Re: [4.2/4.3/4.4 Regression] out of memory while parsing array with
many initializers
Honza, you realize that the numbers are completely unreadable in bugzilla,
right?
THey need some care to read, the columns
--- Comment #5 from sebpop at gmail dot com 2009-02-22 14:55 ---
Subject: Re: [miro] - Revision 144368 - Werror in
../miro/gcc/genconstants.c
I will fix this with the attached patch when approved.
--- Comment #6 from sebpop at gmail dot com 2009-02-22 14:55 ---
--- Comment #6 from spop at gcc dot gnu dot org 2009-02-22 15:03 ---
MIRO is an inactive development branch. I will fix the svn.html page.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from rob1weld at aol dot com 2009-02-22 15:12 ---
(In reply to comment #6)
MIRO is an inactive development branch. I will fix the svn.html page.
Thanks, that is all that is needed.
Rob
BTW: I was only going to run quickly through the code and
check that the 'New and
--- Comment #3 from hjl dot tools at gmail dot com 2009-02-22 15:28 ---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #2 from kargl at gcc dot gnu dot org 2009-02-22 16:05 ---
Please see the Standard's description of RANDOM_SEED. In particular,
what does
program duh
integer how_many
call random_seed(size=how_many)
print '(I0)', how_many
end program duh
do on each system?
More
--- Comment #3 from michael dot a dot richmond at nasa dot gov 2009-02-22
16:21 ---
On Debian 5.0 they return:
mrich...@msc3035298w:~$ gfortran duh.f90
mrich...@msc3035298w:~$ ./a.out
12
mrich...@msc3035298w:~$ gfortran doh.f90
mrich...@msc3035298w:~$ ./a.out
33
I overwrote Debian
--- Comment #7 from steven at gcc dot gnu dot org 2009-02-22 16:21 ---
Works with gcc 4.3, 4.4.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from steven at gcc dot gnu dot org 2009-02-22 16:29 ---
3 years of inaction. What is going to be done about this?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from steven at gcc dot gnu dot org 2009-02-22 16:31 ---
Is this still an issue, with a new Java front end and a new PRE implementation?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23347
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23347
--- Comment #2 from steven at gcc dot gnu dot org 2009-02-22 16:32 ---
Don't see that failure here:
http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg02195.html
FIXED?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from steven at gcc dot gnu dot org 2009-02-22 16:34 ---
Probably a linker bug - INVALID
(and also no progress for 3 years anyway)
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from steven at gcc dot gnu dot org 2009-02-22 16:36 ---
Locations are now handled differently (mapped locations).
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from steven at gcc dot gnu dot org 2009-02-22 16:37 ---
Three years, no progress... Is this still an issue?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #18 from steven at gcc dot gnu dot org 2009-02-22 16:38 ---
Orphaned bug.
HJ?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from paolo dot carlini at oracle dot com 2009-02-22 16:38
---
CC-ing Jason seems a good idea...
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #3 from hjl dot tools at gmail dot com 2009-02-22 16:43 ---
Fixed in 4.4.0.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #19 from hjl dot tools at gmail dot com 2009-02-22 16:52
---
Created an attachment (id=17343)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17343action=view)
The current patch for gcc 4.4.0 revision 144367
--
hjl dot tools at gmail dot com changed:
What
--- Comment #4 from kargl at gcc dot gnu dot org 2009-02-22 16:53 ---
(In reply to comment #3)
On Debian 5.0 they return:
mrich...@msc3035298w:~$ gfortran duh.f90
mrich...@msc3035298w:~$ ./a.out
12
mrich...@msc3035298w:~$ gfortran doh.f90
mrich...@msc3035298w:~$ ./a.out
33
I
--- Comment #6 from tromey at gcc dot gnu dot org 2009-02-22 17:04 ---
I'm not sure that suggestion will work.
My recollection is that the order of checks is specified,
and that allocating memory before the abstract-ness check
would be incorrect.
I didn't confirm this with the spec
--- Comment #1 from tromey at gcc dot gnu dot org 2009-02-22 17:12 ---
This is not really a bug.
In this scenario, cc1 is executed multiple times. Each invocation
overwrites the -MF file.
A fix is not to pass multiple .c files to a given invocation of gcc.
Perhaps we should note
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-02-22 18:46 ---
(In reply to comment #1)
Is this still an issue, with a new Java front end
This was compiling with a .class file and there was no new java front-end only
the .java front-end was ripped out.
and a new PRE
--- Comment #29 from hubicka at gcc dot gnu dot org 2009-02-22 18:46
---
I mean aligned(64).
I guess something like this then?
Index: config/i386/i386.c
===
--- config/i386/i386.c (revision 144373)
+++ config/i386/i386.c
--- Comment #43 from rguenther at suse dot de 2009-02-22 19:03 ---
Subject: Re: [4.2/4.3/4.4 regression] Uses lots of memory when
compiling large initialized arrays
On Sun, 22 Feb 2009, hubicka at gcc dot gnu dot org wrote:
Actual representation of constructor don't seem to be
--- Comment #16 from rguenth at gcc dot gnu dot org 2009-02-22 19:05
---
Yes indeed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from steven at gcc dot gnu dot org 2009-02-22 19:09 ---
Richi, this may be easy to fix on the AIB...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13962
--- Comment #13 from steven at gcc dot gnu dot org 2009-02-22 19:13 ---
Works on the trunk. The .final_cleanup dumps are the same for f and f1, and so
is the asm output.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from hjl dot tools at gmail dot com 2009-02-22 19:21 ---
The ABI warnings are inconsistent:
bash-3.2$ cat u3.i
typedef long long __m128i __attribute__ ((__vector_size__ (16),
__may_alias__));
__m128i
bar2 (void)
{
__m128i x = (__m128i) { 0, 0 };
return x;
}
--- Comment #30 from hjl dot tools at gmail dot com 2009-02-22 19:28
---
(In reply to comment #29)
I mean aligned(64).
I guess something like this then?
Index: config/i386/i386.c
===
--- config/i386/i386.c (revision
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-02-22 20:20 ---
Easy but dangerous ;)
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from rob1weld at aol dot com 2009-02-22 20:39 ---
(In reply to comment #5)
Subject: Re: [miro] - Revision 144368 - Werror in
../miro/gcc/genconstants.c
I will fix this with the attached patch when approved.
Thanks kindly, great results are here:
--- Comment #2 from hjl dot tools at gmail dot com 2009-02-22 22:04 ---
On 32bit, -mno-avx/-mno-sse/-mno-mmx changes ABI for
1. Vector returns.
2. Vector parameters without varargs.
On 64bit,
1. -mno-avx/-mno-sse changes ABI for
a. Float/Vector and aggregate with float/vector
--- Comment #2 from hjl dot tools at gmail dot com 2009-02-22 23:59 ---
Created an attachment (id=17344)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17344action=view)
A patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36411
--- Comment #4 from hjl dot tools at gmail dot com 2009-02-22 23:59 ---
Created an attachment (id=17345)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17345action=view)
A patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37789
--- Comment #2 from steven at gcc dot gnu dot org 2009-02-23 00:41 ---
In fact, with glibc, printf may have side effects to local variables.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39268
--- Comment #1 from rob1weld at aol dot com 2009-02-23 01:21 ---
Confirmed on i386-pc-solaris2.11 (OpenSolaris 2009.06).
We are advised to use libelf v0.8.10, which (by default) installs in
/usr/local but the lto configury uses /usr/include/libelf.h .
+1 for --with-libelf=/usr/local .
--- Comment #6 from hjl dot tools at gmail dot com 2009-02-23 02:36 ---
Created an attachment (id=17346)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17346action=view)
A patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39060
--- Comment #31 from Joey dot ye at intel dot com 2009-02-23 03:15 ---
How about this patch?
1. Only reduce DI mode when -Os
2. Ignore TYPE_USER_ALIGN, so that stack realign happens for case in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39137#c28, which IMHO is
acceptable.
Index:
This code has erroneously been accepted since at least gcc 2.95:
--
namespace NS {
template int A, int B class X {};
}
class Y {
template int friend class NS::X;
};
--
Note the wrong number of template arguments in the friend declaration.
The
--- Comment #2 from rob1weld at aol dot com 2009-02-23 03:51 ---
Rainer, while we wait for the patch did you wish to try this:
1. Edit the gcc/configure (Line 9562) and reverse the detection order:
- for ac_header in gelf.h libelf/gelf.h
+ for ac_header in libelf/gelf.h gelf.h
2.
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2009-02-23 04:37
---
If anyone is looking into this, please let me know if there are any specific
posix calls needed that I should put into the gfc_posix module. ( Priority
wise.)
--
Hello.
The following does not compile:
-
class A
{
public:
class B {};
template class T, class X void x(X a) {}
template class T void x(int a);
};
template class T
void A::x (int a)
{ }
template void A::xA::B (int a);
--
Namely, the explicit instantiation on the last line
Subject: Possible error with C++ compilers on 64 bit PC running
SUSE 10.3 with memory allocation
In C++ you can request space with the new command but if you
repeatedly do this then it should eventually fail. The following
program is designed to illustrate this by first repeatedly
71 matches
Mail list logo
