Daniel Jacobowitz [EMAIL PROTECTED] writes:
All comments welcome - Richard, especially from you. How would you
like to proceed? I think the first step should be to get your other
binutils/gcc patches merged, including MIPS16 PIC; I used those as a
base. But see a few of the notes for
- The rest of the memory utilization difference is mostly in inlining
(240Kb) and SSA update (50Kb).
I think the main focus points should be DSE and trying to get a good
way of measuring the memory utilization differences. Jan, any
suggestion?
I've switched memory tester to tuples now.
On Sun, Jul 27, 2008 at 1:18 PM, Gerald Pfeifer [EMAIL PROTECTED] wrote:
I believe the following happened in the last 48 or so hours; I saw
this triggered by my nightly Wine builds which in turn use my nightly
GCC builds. ;-)
For code like the following where we have an infinite loop in a
I believe the following happened in the last 48 or so hours; I saw
this triggered by my nightly Wine builds which in turn use my nightly
GCC builds. ;-)
For code like the following where we have an infinite loop in a
non-void function, we now (incorrectly) issue a warning with all
of -O0, -O1 and
Dear All,
Perhaps this is old news/my fault but I am seeing the following on
Cygwin_NT/amd64:
/irun/bin/gcc -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -W
missing-prototypes -Wcast-qual -Wold-style-definition -Wc++-compat -Wmissing-for
mat-attribute -pedantic -Wno-long-long
On Sun, Jul 27, 2008 at 1:18 PM, Gerald Pfeifer [EMAIL PROTECTED] wrote:
I believe the following happened in the last 48 or so hours; I saw
this triggered by my nightly Wine builds which in turn use my nightly
GCC builds. ;-)
For code like the following where we have an infinite loop in
The trunk is frozen now until after the merge of the tuples branch
which will happen tomorrow, Monday Jul 28th. Unfreezing of the
trunk will be annonced after the fact.
Thanks,
Richard.
--
Richard Guenther [EMAIL PROTECTED]
Novell / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG
David Edelsohn wrote:
I do not expect LTO (or WHOPR) to work on AIX -- at least not
without a lot of work on wrappers around the AIX linker. However, I do
not understand why enhancing GCC to support LTO -- when GCC is run without
enabling LTO -- requires locking GCC completely into
On Sun, Jul 27, 2008 at 7:18 PM, Mark Mitchell [EMAIL PROTECTED] wrote:
David Edelsohn wrote:
I do not expect LTO (or WHOPR) to work on AIX -- at least not
without a lot of work on wrappers around the AIX linker. However, I do
not understand why enhancing GCC to support LTO -- when
On Sun, Jul 27, 2008 at 11:09 AM, Richard Guenther
[EMAIL PROTECTED] wrote:
We generate variables with names like x$y for struct { int y; } x; - in theory
the debugger could magically associate a print x.y with x$y. But of course
there is no way to express this in the DWARF.
Actually there
On Sun, Jul 27, 2008 at 1:18 PM, Mark Mitchell [EMAIL PROTECTED] wrote:
David Edelsohn wrote:
I do not expect LTO (or WHOPR) to work on AIX -- at least not
without a lot of work on wrappers around the AIX linker. However, I do
not understand why enhancing GCC to support LTO -- when
Andrew Pinski wrote:
Actually there is a way to express this in Dwarf2, using DW_OP_piece.
See the thread at http://gcc.gnu.org/ml/gcc/2005-01/msg00080.html for
more information.
And if that's not sufficient, we can of course add extensions to DWARF
that do represent it -- and that would be
Daniel Berlin wrote:
I agree that, at least in principle, it should be possible to emit the debug
info (whether the format is DWARF, Stabs, etc.) once.
No, you can't.
You would at least have to emit the variables separate from the types
(IE emit debug info twice).
Yes, of course; that's
Daniel Berlin wrote:
On Sun, Jul 27, 2008 at 1:18 PM, Mark Mitchell [EMAIL PROTECTED] wrote:
David Edelsohn wrote:
I do not expect LTO (or WHOPR) to work on AIX -- at least not
without a lot of work on wrappers around the AIX linker. However, I do
not understand why enhancing
Richard Sandiford wrote:
Daniel Jacobowitz [EMAIL PROTECTED] writes:
All comments welcome - Richard, especially from you. How would you
like to proceed? I think the first step should be to get your other
binutils/gcc patches merged, including MIPS16 PIC; I used those as a
base. But see a few
On Sun, Jul 27, 2008 at 3:10 PM, Mark Mitchell [EMAIL PROTECTED] wrote:
Daniel Berlin wrote:
I agree that, at least in principle, it should be possible to emit the
debug
info (whether the format is DWARF, Stabs, etc.) once.
No, you can't.
You would at least have to emit the variables
Daniel Berlin wrote:
On Sun, Jul 27, 2008 at 3:10 PM, Mark Mitchell [EMAIL PROTECTED] wrote:
Daniel Berlin wrote:
I agree that, at least in principle, it should be possible to emit the
debug
info (whether the format is DWARF, Stabs, etc.) once.
No, you can't.
You would at
Daniel Berlin wrote:
Then again, I also don't see what the big deal about adding a debug
info parser is.
OK, yes, we may need to read debug info back in.
I don't see it as a big deal, either -- and I also don't see it as
locking us into DWARF2. We can presumably read in any formats we are
On Sun, Jul 27, 2008 at 7:41 PM, Daniel Berlin [EMAIL PROTECTED] wrote:
On Sun, Jul 27, 2008 at 3:10 PM, Mark Mitchell [EMAIL PROTECTED] wrote:
Daniel Berlin wrote:
I agree that, at least in principle, it should be possible to emit the
debug
info (whether the format is DWARF, Stabs, etc.)
On Sun, Jul 27, 2008 at 7:48 PM, Kenneth Zadeck
[EMAIL PROTECTED] wrote:
Daniel Berlin wrote:
you may of course be right and this is what we will end up doing, but the
implications for whopr are not good. The parser is going to have to work
in lockstep with the type merger
Why?
You don't
On Sun, Jul 27, 2008 at 7:50 PM, Mark Mitchell [EMAIL PROTECTED] wrote:
Daniel Berlin wrote:
Then again, I also don't see what the big deal about adding a debug
info parser is.
OK, yes, we may need to read debug info back in.
I don't see it as a big deal, either -- and I also don't see it
--- Comment #2 from burnus at gcc dot gnu dot org 2008-07-27 07:23 ---
Currently, in interface.c's compare_parameter the checking is done via
compare_interfaces. However, this function is used to check for problems with
generic interfaces and from that point of view the two procedures
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2008-07-27 09:04
---
With some 'make' kludgery, I get the same reproducible error on x86 as Dave.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2008-07-27 09:16
---
This points to an immediate problem in vn_reference_op_compute_hash:
/* Compute the hash for a reference operand VRO1. */
static hashval_t
vn_reference_op_compute_hash (const vn_reference_op_t vro1)
{
return
--- Comment #2 from burnus at gcc dot gnu dot org 2008-07-27 10:46 ---
Subject: Bug 36909
Author: burnus
Date: Sun Jul 27 10:45:44 2008
New Revision: 138186
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=138186
Log:
2008-07-27 Tobias Burnus [EMAIL PROTECTED]
PR
--- Comment #6 from burnus at gcc dot gnu dot org 2008-07-27 10:46 ---
Subject: Bug 29952
Author: burnus
Date: Sun Jul 27 10:45:44 2008
New Revision: 138186
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=138186
Log:
2008-07-27 Tobias Burnus [EMAIL PROTECTED]
PR
--- Comment #10 from burnus at gcc dot gnu dot org 2008-07-27 10:46 ---
Subject: Bug 36132
Author: burnus
Date: Sun Jul 27 10:45:44 2008
New Revision: 138186
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=138186
Log:
2008-07-27 Tobias Burnus [EMAIL PROTECTED]
PR
--- Comment #1 from paolo dot carlini at oracle dot com 2008-07-27 10:53
---
Jason, can you have a look?
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #7 from burnus at gcc dot gnu dot org 2008-07-27 10:54 ---
Now also run-time warnings are printed.
- FIXED on the trunk (4.4).
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from burnus at gcc dot gnu dot org 2008-07-27 10:55 ---
FIXED on the trunk (4.4).
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from burnus at gcc dot gnu dot org 2008-07-27 11:42 ---
Subject: Bug 36132
Author: burnus
Date: Sun Jul 27 11:41:35 2008
New Revision: 138187
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=138187
Log:
2008-07-27 Tobias Burnus [EMAIL PROTECTED]
PR
--- Comment #12 from burnus at gcc dot gnu dot org 2008-07-27 11:47 ---
FIXED on the trunk and on the 4.3 branch. Thanks for the bug report.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from burnus at gcc dot gnu dot org 2008-07-27 13:52 ---
Isn't this maybe a general problem about optional string arguments?
Or is this really a eoshift-specific problem? I'm just thinking about a
general solution for this kind of problem if it isn't.
I think this
--- Comment #3 from w6ws at earthlink dot net 2008-07-27 13:52 ---
Subject: Re: Attributes not fully checked comparing actual
vs dummy procedure
burnus at gcc dot gnu dot org wrote:
If actual-argument procedure itself takes procedures as argument, one can
check
recursively, which
xgcc.exe (GCC; Mingw; 32bit; i686; NLS) 4.3.1
Copyright (C) 2008 Free Software Foundation, Inc.
configure:2369: $? = 0
configure:2371: /c/_GccBuilds/gcc-4.3.1-build/mingw-32-i686/./gcc/xgcc
-B/c/_GccBuilds/gcc-4.3.1-build/mingw-32-i686/./gcc/
--- Comment #2 from andry at inbox dot ru 2008-07-27 14:01 ---
Created an attachment (id=15967)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15967action=view)
libgcc config log
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36948
--- Comment #3 from andry at inbox dot ru 2008-07-27 14:03 ---
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
make[1]: *** [configure-target-libgcc] Error 1
make: *** [all] Error 2
--
andry at inbox dot ru changed:
--- Comment #1 from andry at inbox dot ru 2008-07-27 14:01 ---
Created an attachment (id=15966)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15966action=view)
Root config log
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36948
--- Comment #10 from dberlin at gcc dot gnu dot org 2008-07-27 15:37
---
Subject: Re: [4.4 Regression] STORAGE_ERROR raised compiling s-os_lib.adb
No, it doesn't.
Even if the op isn't hashed, it is still compared for in
vn_reference_op_eq, so at worst the non-hashing will make it
Here's a minimalistic example:
#include memory
struct A : std::enable_shared_from_this A {};
int main()
{
std::make_shared A ()-shared_from_this();
}
It throws a bad_weak_ptr exception, which is AFAICT wrong.
--
Summary: [C++0x] make_shared does not initialize
--- Comment #11 from ebotcazou at gcc dot gnu dot org 2008-07-27 15:58
---
Even if the op isn't hashed, it is still compared for in
vn_reference_op_eq, so at worst the non-hashing will make it compare
more vn_reference_op's than it has to, it shouldn't affect
correctness.
You're
Here's a minimalistic example:
#include memory
struct A : std::enable_shared_from_this A {};
int main()
{
std::make_shared A ()-shared_from_this();
}
It throws a bad_weak_ptr exception, which is AFAICT wrong.
--
Summary: [C++0x] make_shared does not initialize
--- Comment #1 from d dot frey at gmx dot de 2008-07-27 16:19 ---
Sorry, reporting it *once* should be enough :-}
*** This bug has been marked as a duplicate of 36949 ***
--
d dot frey at gmx dot de changed:
What|Removed |Added
--- Comment #1 from dfranke at gcc dot gnu dot org 2008-07-27 16:29 ---
Can not reproduce the problem with 4.4.0 (20080727) on i686-pc-linux-gnu.
Could you please try with a more recent version than 4.4.40 (20080509) whether
the problem still exists for your platform?
--
dfranke
--- Comment #3 from dfranke at gcc dot gnu dot org 2008-07-27 16:32 ---
Subject: Bug 36724
Author: dfranke
Date: Sun Jul 27 16:32:14 2008
New Revision: 138190
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=138190
Log:
2008-07-27 Daniel Franke [EMAIL PROTECTED]
PR
--- Comment #4 from dfranke at gcc dot gnu dot org 2008-07-27 16:33 ---
Reporter can't reproduce problem with current release.
Committed testcase to avoid later regression. Closing.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
GCC host triplet|20080509|
--- Comment #1 from d dot frey at gmx dot de 2008-07-27 16:19 ---
*** Bug 36950 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36949
--- Comment #4 from dfranke at gcc dot gnu dot org 2008-07-27 16:45 ---
Backport becomes more unlikely as trees diverge more and more.
Suggest submitting the testcase to avoid regression and closing as WONTFIX for
4.3.x?
--
dfranke at gcc dot gnu dot org changed:
What
--- Comment #9 from dfranke at gcc dot gnu dot org 2008-07-27 16:55 ---
Anything new here?
Did you try a newer version of gfortran as suggested by Steve?
If it still does not work for you, could you provide a self-contained test
case?
--
dfranke at gcc dot gnu dot org changed:
--- Comment #13 from ebotcazou at gcc dot gnu dot org 2008-07-27 16:58
---
Subject: Bug 36830
Author: ebotcazou
Date: Sun Jul 27 16:57:34 2008
New Revision: 138192
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=138192
Log:
PR tree-optimization/36830
* tree-vn.c
--- Comment #14 from ebotcazou at gcc dot gnu dot org 2008-07-27 17:04
---
Presumably.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from ebotcazou at gcc dot gnu dot org 2008-07-27 16:56
---
Subject: Bug 36830
Author: ebotcazou
Date: Sun Jul 27 16:55:31 2008
New Revision: 138191
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=138191
Log:
PR tree-optimization/36830
*
--- Comment #12 from ebotcazou at gcc dot gnu dot org 2008-07-27 17:11
---
Aaron, could you update your tree and attemp a clean bootstrap? The fix is
supposed to be
2008-07-17 Olivier Hainque [EMAIL PROTECTED]
* utils.c (create_var_decl_1): Relax expectations on the
--- Comment #4 from burnus at gcc dot gnu dot org 2008-07-27 17:13 ---
Withe following patch the ICE is changed to
pr35971_red.f90:33.25:
gp = get_funloc(make_mess,aux)
1
Error: Type/rank mismatch in argument 'x' at (1)
- sym-as =
--- Comment #2 from paolo dot carlini at oracle dot com 2008-07-27 17:32
---
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 __shared_ptr(_Sp_make_shared_tag, _Alloc,
--- Comment #5 from burnus at gcc dot gnu dot org 2008-07-27 17:19 ---
Regarding the test case in comment 2, ifort complains:
fjf.f90(14): error #6487: Local array names may not be used as
IMPORT-name_entities [MY_MESSAGE]
import my_message
^
(my_message is
--- Comment #9 from hjl at gcc dot gnu dot org 2008-07-27 17:40 ---
Subject: Bug 36944
Author: hjl
Date: Sun Jul 27 17:40:04 2008
New Revision: 138194
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=138194
Log:
gcc/cp/
2008-07-27 H.J. Lu [EMAIL PROTECTED]
PR c++/36944
--- Comment #4 from andry at inbox dot ru 2008-07-27 17:52 ---
Seems that crash happens when GCC run with -O2 flag:
make CFLAGS=-O2 CFLAGS_FOR_TARGET=-O2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36948
--
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
--- Comment #22 from hjl dot tools at gmail dot com 2008-07-27 18:59
---
Fixed by revision 138154.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #10 from hjl dot tools at gmail dot com 2008-07-27 18:56
---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #7 from hjl dot tools at gmail dot com 2008-07-27 18:58 ---
Fixed by revision 138154.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #5 from hjl dot tools at gmail dot com 2008-07-27 19:09 ---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #3 from hjl dot tools at gmail dot com 2008-07-27 19:09 ---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #11 from hjl dot tools at gmail dot com 2008-07-27 18:56
---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #12 from hjl dot tools at gmail dot com 2008-07-27 19:11
---
Jim, can you take a look at this patch?
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #2 from tkoenig at gcc dot gnu dot org 2008-07-27 19:28 ---
The test case now correctly complains about
an unneeded temporary:
$ gfortran -Warray-temporaries foo.f90
foo.f90:5.8:
foo = all((/ a, b, c /) /= d)
1
Warning: Creating array temporary at (1)
--
--- Comment #6 from burnus at gcc dot gnu dot org 2008-07-27 19:54 ---
See also http://gcc.gnu.org/ml/fortran/2008-07/msg00211.html
Problem is the libgfortran ABI. Email mentions PR 35718, which presumably also
means an ABI breakage.
--
burnus at gcc dot gnu dot org changed:
Compiling the attached piece of code produces this:
foo.c: In function 'bar':
foo.c:8: warning: 'bar_thing.member' is used uninitialized in this function
but line 8 is in foo(), not bar, and bar_thing isn't in scope.
It has inlined foo (confirmed in the assembler output) and it's
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-07-27 20:35 ---
In 4.3 (maybe even 4.2), we get an extra note:
t.c: In function 'bar':
t.c:8: warning: 'bar_thing.member' is used uninitialized in this function
t.c:12: note: 'bar_thing.member' was declared here
So I think I can
--- Comment #9 from jakub at gcc dot gnu dot org 2008-07-27 20:59 ---
Fixed on the trunk.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from victork at gcc dot gnu dot org 2008-07-27 21:45 ---
Subject: Bug 35252
Author: victork
Date: Sun Jul 27 21:44:25 2008
New Revision: 138198
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=138198
Log:
2008-07-27 Victor Kaplansky [EMAIL PROTECTED]
PR
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2008-07-27 23:25
---
I see only one place in the I/O library that uses GFC_DTYPE_RANK_MASK.
There are many many places in the intrinsics.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36825
74 matches
Mail list logo
