On Mon, 26 Oct 2009, Steve Ellcey wrote:
I have tried:
/* { dg-final { scan-assembler-times (byte|data1).*?0x3.*? DW_AT_inline 3 }
} */
/* { dg-final { scan-assembler-times (byte\|data1).*?0x3.*? DW_AT_inline 3
} } */
/* { dg-final { scan-assembler-times \(byte\|data1\).*?0x3.*?
Hi,
I recently read the articles about the selective scheduling
implementation and found it quite interesting, I especially liked the
idea of how neatly software pipelining is integrated. The target I am
working on is a VLIW DSP so obviously these things are very important
for good code
Steve Ellcey s...@cup.hp.com writes:
I do get this test to pass. But other systems are using 'byte' so of
course I need to allow for either byte or data1. I have tried:
/* { dg-final { scan-assembler-times (byte|data1).*?0x3.*? DW_AT_inline 3 }
} */
/* { dg-final { scan-assembler-times
Hi,
On Tue, 27 Oct 2009, Markus L wrote:
Hi,
I recently read the articles about the selective scheduling
implementation and found it quite interesting, I especially liked the
idea of how neatly software pipelining is integrated. The target I am
working on is a VLIW DSP so obviously these
This means that if your GCC source tree resides in a directory, say,
~/gcc-src
you should *not* run ./configure while in ~/gcc-src. Instead, you
should create a second, empty directory
~/gcc-build
(which is not a subdirectory of ~/gcc-src), and run
../gcc-src/configure ...
while in
Hello All,
I feel that the current plugin hooks, that is the set of plugin events
enumerated in the enum plugin_event of gcc/gcc-plugin.h and the
associated API in gcc/plugin.h (e.g. register_attribute) is perhaps
still incomplete.
My feeling is that adding plugin events (at least those for
On Tue, Oct 27, 2009 at 1:15 PM, Basile STARYNKEVITCH
bas...@starynkevitch.net wrote:
Hello All,
I feel that the current plugin hooks, that is the set of plugin events
enumerated in the enum plugin_event of gcc/gcc-plugin.h and the associated
API in gcc/plugin.h (e.g. register_attribute) is
Richard Guenther wrote:
On Tue, Oct 27, 2009 at 1:15 PM, Basile STARYNKEVITCH
Adding hooks just because you think they might be useful
isn't the way to go.
Then what is the correct way to enhance the current plugin API. There
are a lot of stuff missing there.
I am not at all sure that all
Basile STARYNKEVITCH bas...@starynkevitch.net writes:
Richard Guenther wrote:
On Tue, Oct 27, 2009 at 1:15 PM, Basile STARYNKEVITCH
Adding hooks just because you think they might be useful
isn't the way to go.
Then what is the correct way to enhance the current plugin API. There
are a lot
Hello All,
Richard Guenther wrote:
Adding hooks just because you think they might be useful
isn't the way to go.
Basile STARYNKEVITCH bas...@starynkevitch.net writes:
Then what is the correct way to enhance the current plugin API. There
are a lot of stuff missing there.
Ian Lance
Basile STARYNKEVITCH bas...@starynkevitch.net writes:
Ian Lance Taylor wrote:
We should add hooks as we find plugins that need them. Simply adding
a laundry list of hooks that we think might be needed will most likely
cause us to overdesign. We know that we can write interesting plugins
Ian Lance Taylor wrote:
Basile STARYNKEVITCH bas...@starynkevitch.net writes:
* propose a simple patch to add the PLUGIN_REGISTER_PRAGMA event now?
Do this.
Will do probably tommorow or this evening!
On the other hand, skimming your list of hooks, I really question the
need for, e.g.,
Ian Lance Taylor wrote:
For something like PLUGIN_ADD_CPP_MACROS, the need is clear, but I
think it's an open question we should add a hook or whether the plugin
should just call cpp_define. A hook means that we promise to always
have a way to do this in case cpp_define changes. How do we
Charles Wilson cygwin at cwilson.fastmail.fm writes:
If cygwin wants to be POSIX compatible then the C locale cannot use
UTF-8.
Not true. POSIX has no restrictions against the C locale not being a multi-
byte charset.
The tables in Locale Definition describe the characteristics and
On Tue, Oct 27, 2009 at 4:06 PM, Basile STARYNKEVITCH
bas...@starynkevitch.net wrote:
Ian Lance Taylor wrote:
Basile STARYNKEVITCH bas...@starynkevitch.net writes:
* propose a simple patch to add the PLUGIN_REGISTER_PRAGMA event now?
Do this.
Will do probably tommorow or this evening!
Richard Guenther wrote:
The fix is not to add a hook to replace the pass manager but instead
to make the GCC pass manager more flexible itself.
I leave that task to my ICI friends (in CC). They have already an
implementation, and I believe they probably did propose some patches, or
are
On Tue, 27 Oct 2009, Basile STARYNKEVITCH wrote:
I (Basile) don't know much of libcpp. If a plugin can just call cpp_define,
this is ok for me. But then, we perhaps should document how can that be
called, and when (at plugin initialization, at PLUGIN_START_UNIT? I don't
know!)
A plugin can
On Tue, Oct 27, 2009 at 4:48 PM, Basile STARYNKEVITCH
bas...@starynkevitch.net wrote:
Richard Guenther wrote:
The fix is not to add a hook to replace the pass manager but instead
to make the GCC pass manager more flexible itself.
I leave that task to my ICI friends (in CC). They have already
I agree with H-P.
The attached patch implements that. Tested that it is ignored by cc1
and not passed to the linker. OK with a CL entry if bootstrap finishes
OK?
--
Daniel Jacobowitz
CodeSourcery
Cheers,
--
Rafael Ávila de Espíndola
diff --git a/gcc/common.opt b/gcc/common.opt
index
Rafael Espindola espind...@google.com writes:
diff --git a/gcc/common.opt b/gcc/common.opt
index b57234a..9e4cf12 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -1391,6 +1391,11 @@ funwind-tables
Common Report Var(flag_unwind_tables) Optimization
Just generate unwind tables for
On Tue, 2009-10-27 at 02:09 -0400, Kaveh R. GHAZI wrote:
On Mon, 26 Oct 2009, Steve Ellcey wrote:
I have tried:
/* { dg-final { scan-assembler-times (byte|data1).*?0x3.*? DW_AT_inline 3
} } */
/* { dg-final { scan-assembler-times (byte\|data1).*?0x3.*? DW_AT_inline
3 } } */
/* {
Andreas Schwab sch...@redhat.com writes:
Rafael Espindola espind...@google.com writes:
diff --git a/gcc/common.opt b/gcc/common.opt
index b57234a..9e4cf12 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -1391,6 +1391,11 @@ funwind-tables
Common Report Var(flag_unwind_tables)
The regexp should not use .* in the first place, because . also
matches the newline, and you need to use the non-capturing variant of
the grouping operator.
$ tclsh
% set fd [open ~/src/gcc/gcc/gcc/testsuite/gcc.dg/debug/dwarf2/inline2.s r]
file3
% set text [read $fd]
[...]
% regexp -inline -all
So it looks like the problem isn't in the pattern matching, it is in the
counting.
If I use this:
/* { dg-final { scan-assembler-times data1.*?0x3.*? DW_AT_inline 3 } } */
Everything works. If I change it to:
/* { dg-final { scan-assembler-times (data1|byte).*?0x3.*? DW_AT_inline 3 }
} */
Perhaps this should be an Undocumented option. I don't think you need a
Var anyway.
Without the Var it fails with
cc1: internal compiler error: in common_handle_option, at opts.c:2108
The attached patch changes the option to Undocumented.
Andreas.
Cheers,
--
Rafael Ávila de Espíndola
On Tue, 2009-10-27 at 17:59 +0100, Andreas Schwab wrote:
The regexp should not use .* in the first place, because . also
matches the newline, and you need to use the non-capturing variant of
the grouping operator.
I am not sure what the non-capturing variant of the grouping operator
is. Is
Without the Var it fails with
cc1: internal compiler error: in common_handle_option, at opts.c:2108
Which can also be fixed by explicitly ignoring
OPT_fuse_linker_plugin. The attached patch does that. Any preferences?
Cheers,
--
Rafael Ávila de Espíndola
diff --git a/gcc/common.opt
Sent from my iPhone
On Oct 27, 2009, at 10:13 AM, Rafael Espindola espind...@google.com
wrote:
Perhaps this should be an Undocumented option. I don't think you
need a
Var anyway.
Without the Var it fails with
cc1: internal compiler error: in common_handle_option, at opts.c:2108
Then what about adding to that switch statement that it is already handled
by the specs?
That is what the last version does.
Cheers,
--
Rafael Ávila de Espíndola
Eric Blake wrote:
The correct workaround is indeed to specify a locale with specific charset
encodings, rather than relying on plain C
Yep, I'm testing a patch to that effect.
(hopefully cygwin will support C.ASCII, if it does not already).
Yep, it does.
As far as I know, the hole
Steve Ellcey s...@cup.hp.com writes:
I am not sure what the non-capturing variant of the grouping operator
is. Is that the '?:' ?
Yes, see re_syntax(n).
I have never seen that used in a scan-assembler anywhere else.
None of them use grouping in first place (except for a few by accident).
On Mon, Oct 26, 2009 at 09:40:06AM -0700, Andrew Pinski wrote:
Except (b) is correct as fold should not be modifiying the tree at
all. That is the whole point of fold_checksum_tree. We allow some
things to change like TYPE_VARIANTs and such but we should not allow a
The TYPE_VARIANTs case is
On Fri, Oct 23, 2009 at 09:58:55PM +0800, Zhang Lin wrote:
Hello,
I have encountered an issue when building ACE with MinGW and GCC 4.4.1
The following macro was not accepted by the preprocessor and it reported such
an error: error: operator '==' has no left operand.
#if !defined
On Thu, Oct 22, 2009 at 12:14:31PM -0500, Pranav Bhandarkar wrote:
Are you talking about the tree dead-store elimination pass or
the RTL one? Basically *addr = value1; cannot be removed
if addr does not point to local memory or if the pointed-to
memory escapes through a call-site that is
Snapshot gcc-4.4-20091027 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20091027/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Eric Blake writes:
The correct workaround is indeed to specify a locale with specific charset
encodings, rather than relying on plain C (hopefully cygwin will
support C.ASCII, if it does not already).
The correct fix is for GCC not to intentionally choose to rely on
implementation defined
--- Comment #1 from truedfx at gentoo dot org 2009-10-27 06:26 ---
Same results with the 20091022 snapshot.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41842
gcc -B. -r -nostdlib shape.i -v -Wall -Wextra -Os -fipa-struct-reorg
-fwhole-program -combine
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with:
--- Comment #1 from b3timmons at speedymail dot org 2009-10-27 07:20
---
Created an attachment (id=18911)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18911action=view)
preprocessed source triggering failure
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41843
--- Comment #2 from b3timmons at speedymail dot org 2009-10-27 07:21
---
Created an attachment (id=18912)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18912action=view)
preprocessed source triggering failure
Had to compress source because of submission timing out
--
--- Comment #3 from b3timmons at speedymail dot org 2009-10-27 07:25
---
A workaround for gcc-4,3,3 (but not gcc-4.5.0!) is -fno-unit-at-a-time
--
b3timmons at speedymail dot org changed:
What|Removed |Added
--- Comment #2 from jakub at gcc dot gnu dot org 2009-10-27 08:18 ---
Created an attachment (id=18913)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18913action=view)
gcc45-pr41842.patch
Fix I'm going to bootstrap/regtest.
--
jakub at gcc dot gnu dot org changed:
$cat test.f90
program main
end
$gfortran -flto -ffixed-line-length-none test.f90
lto1: warning: unknown register name: line-length-none
I think -ffixed-line-length-none has nothing to do with lto, am I right?
--
Summary: lto1: warning: unknown register name: line-length-none
--- Comment #6 from marti at juffo dot org 2009-10-27 08:58 ---
(In reply to comment #5)
These might not be bogus as there is extra inlining at -O3 which causes us to
strip out the address taking and make search_table_entries, etc. look like
real variables.
True, I have changed the
The following should not compile, since the Limited_Controlled has no Adjust
operation and the test code uses the overriding keyword, which is supposed to
catch the attempt to override non-existing operation. Other operation names are
detected properly, which indicates that there is some hidden
--- Comment #4 from carrot at google dot com 2009-10-27 09:15 ---
A patch http://gcc.gnu.org/viewcvs?view=revisionrevision=153584 has been
checked in.
--
carrot at google dot com changed:
What|Removed |Added
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-10-27 09:37 ---
Doh, thanks. It's obvious to me what is wrong.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from mathieu dot malaterre at gmail dot com 2009-10-27
09:43 ---
Copying from the mailing list:
fromAndrew Haley a...@redhat.com
to Tom Tromey tro...@redhat.com
cc j...@gcc.gnu.org
dateMon, Oct 19, 2009 at 5:03 PM
subject Re: Is gcj dead?
mailing list
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-10-27 09:43 ---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #21 from jaffe at broadinstitute dot org 2009-10-27 09:45
---
Subject: Re: [parallel-mode] parallel sort run time
increases ~10 fold when vector size gets over ~4*10^9
I tested the patch from comment #19, sorting X billion integers on a machine
having
32 processors and
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-10-27 10:20 ---
Confirmed. -combine is not necessary. IPA struct-reorg is known to be broken.
Program received signal SIGSEGV, Segmentation fault.
0x00c6123c in find_field_in_struct_1 (str_type=0x76c4a6e0,
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-10-27 10:23 ---
Confirmed. -combine is not necessary. IPA struct reorg is known to be broken.
Program received signal SIGSEGV, Segmentation fault.
0x00c624ee in finalize_global_creation (var=0x0)
at
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-10-27 10:27 ---
Hm. Looks like the driver should filter FE specific options (there is a
general option named -ffixed-X where X is a register).
Workaround: split compile and link step, omit FE specific options from the link
step.
--- Comment #12 from jakub at gcc dot gnu dot org 2009-10-27 10:29 ---
Subject: Bug 41020
Author: jakub
Date: Tue Oct 27 10:28:48 2009
New Revision: 153587
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=153587
Log:
PR c++/41020
* g++.dg/lookup/extern-c-redecl5.C:
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-10-27 10:30 ---
Because 3.3 is wrong. You are creating a pointer to an array of 10 mybase,
but instantiating mybase is not valid. An array of 10 pointers would be
mybase *ptrs[10];
instead.
--
rguenth at gcc dot gnu dot
--- Comment #5 from aldyh at gcc dot gnu dot org 2009-10-27 11:18 ---
Subject: Bug 41451
Author: aldyh
Date: Tue Oct 27 11:18:12 2009
New Revision: 153588
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=153588
Log:
PR bootstrap/41451
* fold-const.c
--- Comment #6 from aldyh at gcc dot gnu dot org 2009-10-27 11:19 ---
fixed
--
aldyh at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-10-27 11:31 ---
Subject: Bug 41821
Author: rguenth
Date: Tue Oct 27 11:30:59 2009
New Revision: 153589
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=153589
Log:
2009-10-27 Richard Guenther rguent...@suse.de
PR
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-10-27 11:31 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #6 from jakub at gcc dot gnu dot org 2009-10-27 12:24 ---
Created an attachment (id=18914)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18914action=view)
gcc45-pr41837.patch
Possible fix and reduced testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41837
--- Comment #3 from michael dot baudin at scilab dot org 2009-10-27 13:32
---
You are right, this was a bug in the fortran source code.
I cannot add implicit none in this slatec/gamma routine, but
declaring the return type of the function fixes the bug.
Thank your for looking at this
--- Comment #6 from jamborm at gcc dot gnu dot org 2009-10-27 13:59 ---
The problem here is that build_ref_for_offset_1() cannot find a field
corresponding to a replacement within its own aggregate. The field is
identified by its offset (zero) and type. Unfortunately,
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-10-27 14:17 ---
As I said the testcase has two incompatible variants of union tree_node and
they are obviously not merged and thus not compatible. Maybe IPA SRA gets
those two types from unrelated places?
--
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-10-27 14:22 ---
Using c-parser.i and c-typeck.i generated from my current trunk tree passes
gcc ./xgcc -B. -r -nostdlib xc-parser.i xc-typeck.i -O2 -flto
just fine. Raphael, was this by chance an ICE you saw during reduction of
--- Comment #3 from jakub at gcc dot gnu dot org 2009-10-27 14:28 ---
Created an attachment (id=18915)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18915action=view)
gcc45-pr41841.patch
Fix.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41841
# gcc -Wall -O2 -c demo.cxx
demo.cxx: In function void isInvertible():
demo.cxx:12: warning: array subscript is above array bounds
gcc --version
gcc (GCC) 4.4.2 20091019 (Red Hat 4.4.2-5)
I've the same results with...
gcc (GCC) 4.4.2 20091019 (Red Hat 4.4.2-5) (gcc-4.4.2-5.el6.s390x)
gcc
--- Comment #1 from caolanm at redhat dot com 2009-10-27 14:47 ---
Created an attachment (id=18916)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18916action=view)
standalone demo
gcc -Wall -O2 -c demo.cxx
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41847
--- Comment #13 from ramana at gcc dot gnu dot org 2009-10-27 14:58 ---
(In reply to comment #0)
when binutils 2.20 branch is built with gcc-4.4 branch or trunk, I see the
following test failures in the ld testsuite. Checked with gcc-4.4 from
debian/testing, debian/unstable and
Look at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41684#c10 for a list of
test failures fixed by disabling fsection-anchors in the arm backend.
Look also at the way in which the PPC backend works around this at
http://gcc.gnu.org/ml/gcc-patches/2008-08/msg02194.html
Instead of putting in
--- Comment #5 from jakub at gcc dot gnu dot org 2009-10-27 15:37 ---
Reduced testcase (although, with a different error). -O -fipa-struct-reorg
-fwhole-program:
struct S { void *a; struct V *b; };
typedef struct { int c; } T;
typedef struct { int d; int e; } U;
void fn (void *);
void
--- Comment #3 from jakub at gcc dot gnu dot org 2009-10-27 15:51 ---
Subject: Bug 41842
Author: jakub
Date: Tue Oct 27 15:50:50 2009
New Revision: 153599
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=153599
Log:
PR c/41842
* c-typeck.c (convert_arguments):
--- Comment #22 from paolo dot carlini at oracle dot com 2009-10-27 15:53
---
Patch regtests fine on x86_64-linux. Johannes, can you prepare a ChangeLog
entry, post and commit both? Thanks!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40852
--- Comment #4 from jakub at gcc dot gnu dot org 2009-10-27 16:05 ---
Subject: Bug 41842
Author: jakub
Date: Tue Oct 27 16:05:36 2009
New Revision: 153602
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=153602
Log:
PR c/41842
* c-typeck.c (convert_arguments):
--- Comment #5 from jakub at gcc dot gnu dot org 2009-10-27 16:06 ---
Fixed on trunk and 4.4 branch.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from boz_gnu at boz dot org dot uk 2009-10-27 16:22 ---
Created an attachment (id=18917)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18917action=view)
Proposed patch
Looks like all we were missing was a check on CLASS_TYPE_P before calling
--- Comment #2 from jakub at gcc dot gnu dot org 2009-10-27 16:33 ---
Reproduceable on today's trunk as well (s390x-linux target).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41847
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-10-27 16:37 ---
Patch which I am testing:
Index: testsuite/gcc.target/powerpc/altivec-33.c
===
--- testsuite/gcc.target/powerpc/altivec-33.c (revision 0)
+++
--- Comment #3 from jakub at gcc dot gnu dot org 2009-10-27 16:53 ---
The issue is that for some strange reason VRP sees the loop iterator (which is
[0, 4) ) as VARYING. Then the fDum = get(b, b) is called when
b is not 3, and get uses the return maLine[nRow].get(nColumn); for nRow 3.
--- Comment #4 from ktietz at gcc dot gnu dot org 2009-10-27 17:16 ---
Applied to trunk at revision 153606.
--
ktietz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from jamborm at gcc dot gnu dot org 2009-10-27 18:04 ---
I have just sent the patch to the mailing list:
http://gcc.gnu.org/ml/gcc-patches/2009-10/msg01625.html
I had to change the testcase a bit so that it compiles on x86_64.
--
--- Comment #2 from rth at gcc dot gnu dot org 2009-10-27 18:12 ---
Mine.
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc
--- Comment #2 from espindola at gcc dot gnu dot org 2009-10-27 18:17
---
Subject: Bug 41652
Author: espindola
Date: Tue Oct 27 18:17:13 2009
New Revision: 153610
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=153610
Log:
2009-10-27 Dmitry Gorbachev d.g.gorbac...@gmail.com
--- Comment #9 from jamborm at gcc dot gnu dot org 2009-10-27 18:39 ---
Hi,
(In reply to comment #7)
Maybe IPA SRA gets
those two types from unrelated places?
I believe they are quite elated. The body of the function is:
bb 2:
init = c_parser_initializer (0B); [return slot
--- Comment #19 from jamborm at gcc dot gnu dot org 2009-10-27 18:45
---
I have downloaded binutils 2.20 and compiled the file on a native ia64
compiler. I have only managed to look at the dumps but so far could
not see any problem there. I will have another look on Thursday.
--
If i use global register variables that are used and updated inside an
interrupt the optimizer produces broken code.
Code example:
register volatile unsigned char timer0_h8 asm(r3);
volatile unsigned char timer0_h8_buf = 0;
void foo(void)
{
timer0_h8_buf = timer0_h8;
return;
}
--- Comment #5 from ubizjak at gmail dot com 2009-10-27 19:35 ---
(In reply to comment #4)
I have just sent the patch to the mailing list:
http://gcc.gnu.org/ml/gcc-patches/2009-10/msg01625.html
I had to change the testcase a bit so that it compiles on x86_64.
You should also
As reported by Thomas Robitaille at
http://gcc.gnu.org/ml/fortran/2009-10/msg00220.html
the following code gives wrong-code (segfault/buserror) at run time with GCC
4.2/4.3/4.4/4.5. (4.1 does not support allocatable dummies.)
$ ./a.out
in sub1
Bus error
module test_module
implicit none
I am building a plugin and would like to use some of the macros defined in
flags.h, but that file is not installed in the plugin/include directory.
--
Summary: PLUGIN_HEADERS missing flags.h
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
gcc -B. -r -nostdlib atom.i -v -Wall -Wextra -O -fmodulo-sched -fprofile-use
-freorder-blocks-and-partition
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with:
--- Comment #3 from rth at gcc dot gnu dot org 2009-10-27 20:09 ---
Subject: Bug 41819
Author: rth
Date: Tue Oct 27 20:09:07 2009
New Revision: 153615
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=153615
Log:
PR c++/41819
* tree-eh.c
--- Comment #4 from rth at gcc dot gnu dot org 2009-10-27 20:11 ---
Fixed.
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from b3timmons at speedymail dot org 2009-10-27 20:11
---
Created an attachment (id=18918)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18918action=view)
gzipped preprocessed source triggering failure
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41852
--- Comment #2 from b3timmons at speedymail dot org 2009-10-27 20:15
---
Created an attachment (id=18919)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18919action=view)
generated gcda file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41852
--- Comment #3 from b3timmons at speedymail dot org 2009-10-27 20:16
---
Created an attachment (id=18920)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18920action=view)
generated gcno file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41852
--- Comment #4 from caolanm at redhat dot com 2009-10-27 20:17 ---
At runtime of the original version of one of these loops (or a similar one, I
decided for ease to boil down to the warning case for this bug) goes way past
the RowSpan limits. If this one is cosmetic, then I've got
--- Comment #3 from d dot g dot gorbachev at gmail dot com 2009-10-27
22:05 ---
Fixed.
--
d dot g dot gorbachev at gmail dot com changed:
What|Removed |Added
$ gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--- Comment #1 from molgrum at yahoo dot se 2009-10-27 23:56 ---
Created an attachment (id=18921)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18921action=view)
Preprocessed file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41853
--- Comment #2 from paolo dot carlini at oracle dot com 2009-10-28 00:21
---
FSF gcc-4.2.x isn't maintained anymore. I would suggest trying to reproduce the
issue with gcc-4.4.x (or at least 4.3.x) or reporting to Ubuntu.
--
paolo dot carlini at oracle dot com changed:
--- Comment #3 from bangerth at gmail dot com 2009-10-28 05:17 ---
(In reply to comment #0)
There are many other such deviations we noticed in this compiler from the
normal C++ principles.
In addition to the previous answer: since gcc3.3, many many bugs have been
fixed where gcc
100 matches
Mail list logo
