--- Comment #32 from burnus at gcc dot gnu dot org 2008-10-23 06:18 ---
(In reply to comment #31)
> Fixed on trunk, backport to 4.3?
I think it is simple enough to be OK.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37707
--- Comment #31 from jvdelisle at gcc dot gnu dot org 2008-10-23 02:50
---
Fixed on trunk, backport to 4.3?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37707
--- Comment #30 from jvdelisle at gcc dot gnu dot org 2008-10-23 02:43
---
Subject: Bug 37707
Author: jvdelisle
Date: Thu Oct 23 02:42:36 2008
New Revision: 141318
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141318
Log:
2008-10-22 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #29 from jvdelisle at gcc dot gnu dot org 2008-10-23 02:32
---
Subject: Bug 37707
Author: jvdelisle
Date: Thu Oct 23 02:31:00 2008
New Revision: 141317
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141317
Log:
2008-10-22 Jerry DeLisle <[EMAIL PROTECTED]
--- Comment #8 from manu at gcc dot gnu dot org 2008-10-23 01:48 ---
Marked as FIXED then. Thanks for the report.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #4 from sebpop at gmail dot com 2008-10-23 01:31 ---
Subject: Re: [graphite] ICE: Segmentation fault
On Wed, Oct 22, 2008 at 7:28 PM, grosser at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
> Proposed fix in gloog()
>
> I added a fix for this SEGFAULT. But now we fail wit
--- Comment #7 from eric dot weddington at atmel dot com 2008-10-23 00:56
---
Confirmed fixed on AVR target.
Thanks Jakub!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37020
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-10-23 00:50 ---
This looks like the same as PR 37893.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37899
On Linux/ia64, revision 141275 gave
+FAIL: StringBuffer_1 -O3 -findirect-dispatch execution - source compiled test
+FAIL: StringBuffer_1 -O3 execution - source compiled test
+FAIL: StringBuffer_1 -findirect-dispatch execution - source compiled test
+FAIL: StringBuffer_1 execution - source compiled
On Linux/ia32, revision 141305 gave:
libtool: compile: /export/gnu/import/svn/gcc-test/bld/gcc/gcj
-B/export/gnu/import/svn/gcc-test/bld/i686-pc-linux-gnu/libjava/
-B/export/gnu/import/svn/gcc-test/bld/gcc/ -ffloat-store -fomit-frame-pointer
-Usun -fclasspath= -fbootclasspath=../../../src-trunk/l
--- Comment #3 from grosser at gcc dot gnu dot org 2008-10-23 00:28 ---
Created an attachment (id=16532)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16532&action=view)
Proposed fix in gloog()
I added a fix for this SEGFAULT. But now we fail with:
copy_data.c: In function 'copy_
--- Comment #3 from bkoz at gcc dot gnu dot org 2008-10-22 23:07 ---
Can work around this by adding initializer_list ctor.
b(std::initializer_list __a)
: t(*__a.begin()) { }
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37860
--- Comment #1 from bkoz at gcc dot gnu dot org 2008-10-22 22:59 ---
Breaking these out to separate bugs
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
Aggregate defined in 8.5.1 as:
An aggregate is an array or a class (Clause 9) with no user-provided
constructors (12.1), no private or protected non-static data members (Clause
11), no base classes (Clause 10), and no virtual functions (10.3).
Perhaps this is an aggregate:
struct aggregate
{
--- Comment #1 from doko at ubuntu dot com 2008-10-22 22:57 ---
can't see these with 141308: please could you recheck?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37893
--
janis at gcc dot gnu dot org changed:
What|Removed |Added
CC||bje at gcc dot gnu dot org
AssignedTo|unassigned at gcc dot gnu
The decNumber package in GCC provides support for decimal floating point
arithmetic in the compiler and, for the DPD format, in libgcc's runtime support
for decimal float. Some of the code in decNumber violates C's strict-aliasing
rules and has resulted in warnings for quite some time. Some of th
This is similar to PR/37860, but for array forms.
#include
struct standard_layout_base
{
int i;
standard_layout_base() = default;
~standard_layout_base() = default;
standard_layout_base& operator=(const standard_layout_base&) = delete;
standard_layout_base(const standard_layout_base&)
--- Comment #2 from bkoz at gcc dot gnu dot org 2008-10-22 22:30 ---
Changed summary
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
Summary|defaul
--- Comment #5 from hp at gcc dot gnu dot org 2008-10-22 22:17 ---
Created an attachment (id=16531)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16531&action=view)
Reduced test-case for updated cris.h at r141228. Compile with -O2.
After fixing REGNO_REG_CLASS (but still with the
--- Comment #4 from hp at gcc dot gnu dot org 2008-10-22 22:05 ---
Created an attachment (id=16530)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16530&action=view)
Updated cris.h patch, reflecting corrected REGNO_REG_CLASS together with the
IRA_COVER_CLASSES.
I tried this updated
--- Comment #1 from grosser at gcc dot gnu dot org 2008-10-22 21:39 ---
Update status details:
With "-O1 -fgraphite-identity" we have:
- No problems:
aermod.f90
ac.f90
air.f90
doduc.f90
linpk.f90
mdbx.f90
tfft.f90
- Fail in expand_scalar_variables_expr()
--- Comment #2 from grosser at gcc dot gnu dot org 2008-10-22 21:32 ---
(In reply to comment #1)
> Created an attachment (id=16512)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16512&action=view) [edit]
> Reduced Test Case
>
This test case does not work, as it is missing a modul
--- Comment #5 from jakub at gcc dot gnu dot org 2008-10-22 21:22 ---
Couldn't cmath just use:
template
inline
typename __gnu_cxx::__promote_2<
-typename __gnu_cxx::__enable_if<__is_arithmetic<_Tp>::__value
-&& __is_arithmetic<_Up>::__value,
+typename __gnu_c
I carefully followed the instructions how to write proper inline assembly for
avr-gcc, however, the resulting code didn't work. I tracked down the problem
and came to the conclusion that gcc assigned wrong registers to the output
variable and therefore corrupted my input data.
Here's sample code,
--- Comment #2 from grosser at gcc dot gnu dot org 2008-10-22 21:18 ---
Here a backtrace for copy_data.c:
#0 0x08194e97 in create_empty_loop_on_edge (entry_edge=0x290c2ac8,
initial_value=0x29066ce8, stride=0x29066d04, upper_bound=0x29066d04,
iv=0x29106ec8,
iv_before=0xbfbfe78
This is a summary bug to keep track of open bugs in compiling polyhedron with
graphite.
At the moment it compiles with -fgraphite, but fails with -fgraphite-identity.
The status in detail for graphite-branch and -fgraphite-identity:
- Without problems:
aermod.f90
ac.f90
air.f90
--- Comment #5 from sebpop at gmail dot com 2008-10-22 21:08 ---
Subject: Re: bootstrap forever with BOOT_CFLAGS="-O2 -ftree-loop-distribution"
> Sebastian, can you please look at this?
Sorry for having missed this bug. The problem here is that we end
with two identical loops, as we
At revision 141303, bootstrap failed with
...
libtool: compile: /opt/gcc/i686-darwin/gcc/gcj
-B/opt/gcc/i686-darwin/i686-apple-darwin9/x86_64/libjava/
-B/opt/gcc/i686-darwin/gcc/ -ffloat-store -fomit-frame-pointer -Usun
-fclasspath= -fbootclasspath=../../../../gcc-4.4-work/libjava/classpath/lib
-
--- Comment #5 from jakub at gcc dot gnu dot org 2008-10-22 20:09 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from jakub at gcc dot gnu dot org 2008-10-22 20:09 ---
Subject: Bug 37882
Author: jakub
Date: Wed Oct 22 20:08:01 2008
New Revision: 141306
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141306
Log:
PR middle-end/37882
* fold-const.c (build_range_t
--- Comment #2 from grosser at gcc dot gnu dot org 2008-10-22 20:05 ---
Polyhedron also fails with this bug in, if you use -fgraphite-identity in the
graphite branch.
bug.f90: In function 'sw':
bug.f90:6: internal compiler error: in expand_scalar_variables_expr, at
graphite.c:3618
capa
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-10-22 19:38 ---
This seem related to PR 33344.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37892
--- Comment #9 from jakub at gcc dot gnu dot org 2008-10-22 19:00 ---
I think either data->passed_type being passed always, or what I've posted,
should be correct. emit_group_store is run on the hard register(s) in which it
is passed, so using data->nominal_type would be unexpected.
Er
--- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca 2008-10-22
18:38 ---
Subject: Re: [4.4 Regression] gcc.dg/compat//scalar-by-value-4_x.c:72: ICE: in
emit_group_store, at expr.c:2084
> --- Comment #6 from jakub at gcc dot gnu dot org 2008-10-22 16:13 ---
> Could be a
--- Comment #3 from jakub at gcc dot gnu dot org 2008-10-22 18:23 ---
Subject: Bug 37882
Author: jakub
Date: Wed Oct 22 18:21:55 2008
New Revision: 141303
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141303
Log:
PR middle-end/37882
* fold-const.c (build_range_t
--- Comment #7 from manu at gcc dot gnu dot org 2008-10-22 18:19 ---
The return is generated because we generate one (if there is none) everytime we
reach the end of a function. This is used later to produce "control reaches end
of non-void function". The compiler-generated try-catch for
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37892
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-10-22 18:16 ---
Created an attachment (id=16528)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16528&action=view)
patch for phi-translation
Patch fixing the phi-translation deficiency, adding a simple optimization to
remove *
struct X { int i; };
int foo (int x)
{
struct X a;
struct X b;
struct X *p;
a.i = 1;
b.i = 2;
if (x)
p = &a;
else
p = &b;
return p->i;
}
should be optimized to return 1 or 2, removing the loads on both paths.
One piece that is missing is that PHI-translation does not opti
--- Comment #3 from spop at gcc dot gnu dot org 2008-10-22 18:08 ---
Subject: Bug 37891
Author: spop
Date: Wed Oct 22 18:06:40 2008
New Revision: 141301
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141301
Log:
2008-10-22 Sebastian Pop <[EMAIL PROTECTED]>
PR tree-opt
--- Comment #2 from spop at gcc dot gnu dot org 2008-10-22 18:07 ---
Fixed.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #1 from sebpop at gmail dot com 2008-10-22 18:04 ---
Subject: Re: New: [graphite-branch] Invalid use of single_succ_edge in
create_single_entry_edge
> Commit 141283 introduced new code in create_single_entry_edge, that breaks
> polyhedron in linpk.f90, mdbx.f90, protein.f90
--- Comment #3 from hp at gcc dot gnu dot org 2008-10-22 18:02 ---
(In reply to comment #2)
> The problem is in that hard regs (like r10) which have class GENERAL_REGS
> (from
> REGNO_REG_CLASS) are translated into ACR_REGS.
Oops, I guess I should make that NONACR_REGS; the documentati
Commit 141283 introduced new code in create_single_entry_edge, that breaks
polyhedron in linpk.f90, mdbx.f90, protein.f90, rnflow.f90, test_fpu.f90:
The code added was:
{
+ edge e = single_succ_edge (region->entry);
+ int e_flags = e->flags;
+ int b_flags = region->entry->flag
--- Comment #8 from manu at gcc dot gnu dot org 2008-10-22 17:05 ---
(In reply to comment #7)
>
> testcase compiles on recent 4.3 with -m{32,64} -O{0..3} w/ boost-1.36.0.
> it needs ~1second/~120MB on my quad core box.
>
Thanks Pawel! If you could test also a recent GCC 4.4 that would
--- Comment #7 from pluto at agmk dot net 2008-10-22 16:58 ---
(In reply to comment #6)
> I cannot compile this testcase with GCC 4.3.2 or a recent revision of GCC
> 4.4.
>
> Could you recreate the prepocessed source with those compilers?
>
testcase compiles on recent 4.3 with -m{32
--- Comment #5 from manu at gcc dot gnu dot org 2008-10-22 16:45 ---
This is FIXED in GCC 4.4
Thanks for the report.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #4 from manu at gcc dot gnu dot org 2008-10-22 16:34 ---
Subject: Bug 30949
Author: manu
Date: Wed Oct 22 16:33:17 2008
New Revision: 141298
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141298
Log:
2008-10-22 Manuel López-Ibáñez <[EMAIL PROTECTED]>
PR
--- Comment #5 from jakub at gcc dot gnu dot org 2008-10-22 16:28 ---
If the array has known bounds, we could say that accesses above bounds trap
and likely it wouldn't hurt much. But for
extern const char *reg_names[];
where we don't know the bounds, we'd have to assume the worst, i.e.
--- Comment #8 from burnus at gcc dot gnu dot org 2008-10-22 16:27 ---
> > Confirm. While I do not get any crash like Dominique, valgrind shows that
> > there is a problem:
>
> How do you extract this diagnostic from valgrind? I have never used it before
> but found it rolled into FC9.
--- Comment #6 from jakub at gcc dot gnu dot org 2008-10-22 16:13 ---
Could be also a dup of PR37316.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37318
--- Comment #1 from jakub at gcc dot gnu dot org 2008-10-22 16:11 ---
My bet would be this is a dup of PR37316. Can you try the patch in there and
see whether it fixes these? If not, make sure all the tests are compiled with
-DDBG (or add #define DBG 1 to the start of struct-layout-1.h
--- Comment #12 from sebpop at gmail dot com 2008-10-22 16:10 ---
Subject: Re: [4.4 Regression] gcc-4.4 regression: incorrect code generation
with -O1 -ftree-vectorize
> common base. Consider &s.c[1] and &s + i, obviously the accesses can
> overlap - would you still say so if the base
> common base. Consider &s.c[1] and &s + i, obviously the accesses can
> overlap - would you still say so if the base address of the first one
> would be &s.c[0]?
Yes, in the case &s.c[1] versus &s.c[0], we still have to consider the
arrays to potentially overlap.
> (really the base address of a
--- Comment #8 from drow at gcc dot gnu dot org 2008-10-22 15:48 ---
Subject: Re: [4.4 Regression] Small structs are not
passed correctly on hppa64-*-*
On Wed, Oct 22, 2008 at 03:37:09PM -, jakub at gcc dot gnu dot org wrote:
> Was the "I am reasonably sure it will only aff
--- Comment #7 from jakub at gcc dot gnu dot org 2008-10-22 15:37 ---
Was the "I am reasonably sure it will only affect only E500" comment in
http://gcc.gnu.org/ml/gcc-patches/2008-06/msg00255.html
meant for this patch or the other one?
Clearly it makes a big difference.
I think the bug
--- Comment #7 from pault at gcc dot gnu dot org 2008-10-22 15:30 ---
(In reply to comment #3)
> Confirm. While I do not get any crash like Dominique, valgrind shows that that
> there is a problem:
>
> ==20532== Invalid write of size 8
> ==20532==at 0x463933: resolve_code (resolve.c
--- Comment #3 from joel at gcc dot gnu dot org 2008-10-22 15:13 ---
Occurs on powerpc-rtems4.10 as well.
+===GNAT BUG DETECTED==+
| 4.4.0 20081014 (experimental) [trunk revision 141108]
(powerpc-unknown-rtems4.10) GCC error:|
| in vt_
--- Comment #20 from jamborm at gcc dot gnu dot org 2008-10-22 15:09
---
OK, here is the status regarding the trunk (4.4) and the test cases
posted here:
1. The test case in the bug description now works in the sense that
funk is inlined even when not performing early inlining becau
This might be related:
the following code compiled with gcc version 4.3.0 20080428 (Red Hat 4.3.0-8):
namespace A{
int x = 1;
}
int main()
{
namespace B = A;
return 0;
}
producdes the following debuginfo:
...
<1><4f>: Abbrev Number: 5 (DW_TAG_subprogram)
<50> DW_AT_external:
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-10-22 14:28 ---
trunk is also broken the same way.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca 2008-10-22
14:28 ---
Subject: Re: [4.4 Regression] Small structs are not passed correctly on
hppa64-*-*
>Priority|P3 |P1
I haven't had a chance to look at this any further but this regress
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-10-22 14:26 ---
Confirmed. This is ifcvt at work, ce1 is buggy already (it probably thinks
accesses to reg_names cannot trap).
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from dominiq at lps dot ens dot fr 2008-10-22 14:24 ---
I am not 100% sure that the following is due to the patch in comment #1, but
the following code segfaults (at the write) after having applied it:
integer :: i(1) = 1
integer :: foo(3)
foo = 17
print *, i, foo
--- Comment #9 from vmakarov at redhat dot com 2008-10-22 14:00 ---
The performance status is still the same. But I am working on it and actually
biggest part of my work time (about 90%) I spent on performance problems
particular this one. They are the most hard to solve.
--
http:
--- Comment #2 from vmakarov at redhat dot com 2008-10-22 13:51 ---
The problem is in that hard regs (like r10) which have class GENERAL_REGS (from
REGNO_REG_CLASS) are translated into ACR_REGS. Such translation results in
wrong register pressure calculation for ACR_REGS and failed asse
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-10-22 13:49 ---
Backporting the fix turns out to be tricky...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37868
--- Comment #8 from drow at gcc dot gnu dot org 2008-10-22 13:31 ---
Subject: Bug 1646
Author: drow
Date: Wed Oct 22 13:30:19 2008
New Revision: 141292
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141292
Log:
./
PR gdb/921
PR gdb/1646
PR gdb/217
--- Comment #4 from drow at gcc dot gnu dot org 2008-10-22 13:31 ---
Subject: Bug 2176
Author: drow
Date: Wed Oct 22 13:30:19 2008
New Revision: 141292
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141292
Log:
./
PR gdb/921
PR gdb/1646
PR gdb/217
--- Comment #4 from drow at gcc dot gnu dot org 2008-10-22 13:31 ---
Subject: Bug 921
Author: drow
Date: Wed Oct 22 13:30:19 2008
New Revision: 141292
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141292
Log:
./
PR gdb/921
PR gdb/1646
PR gdb/2175
--- Comment #3 from drow at gcc dot gnu dot org 2008-10-22 13:31 ---
Subject: Bug 2175
Author: drow
Date: Wed Oct 22 13:30:19 2008
New Revision: 141292
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141292
Log:
./
PR gdb/921
PR gdb/1646
PR gdb/217
--- Comment #41 from amylaar at gcc dot gnu dot org 2008-10-22 13:16
---
(In reply to comment #0)
> 1) Hoists a register containing 0 out of the loop
Does the TARGET_RTX_COSTS set the cost to zero for the constant zero?
--
amylaar at gcc dot gnu dot org changed:
What
--- Comment #2 from mikael dot morin at tele2 dot fr 2008-10-22 12:52
---
I forgot to say that it is regression tested on x86_64-unknown-linux-gnu
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36091
--- Comment #5 from jsm28 at gcc dot gnu dot org 2008-10-22 12:57 ---
Does the execution failure still exist after my patch
2008-09-17 Joseph Myers <[EMAIL PROTECTED]>
* expr.c (emit_group_store): Do not shift before moving via a
stack slot.
?
--
http://gcc.gnu.
--- Comment #1 from krebbel at gcc dot gnu dot org 2008-10-22 12:51 ---
The problem again (similar to PR37674) seems to be related to the
propagation of the hard reg conflict sets in ira_flattening. The
conflict sets are only propagated to the parent allocno if the child
allocno uses th
--- Comment #1 from mikael dot morin at tele2 dot fr 2008-10-22 12:49
---
Created an attachment (id=16527)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16527&action=view)
patch solving the problem
This patch keeps the original array descriptor from gfc_conv_subref_array_arg
to g
--- Comment #2 from jakub at gcc dot gnu dot org 2008-10-22 12:11 ---
That sounds just too strict testcase matching, not expecting any kind of
reordering and .section directives not necessarily being emitted if an object
is emitted in the same section as the previous one.
FYI, on a x86_6
--- Comment #2 from hp at gcc dot gnu dot org 2008-10-22 11:55 ---
A user reports that 4.2.3 worked.
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
Known
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-10-22 11:46 ---
4.2 works, so this is a regression. Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #8 from jakub at gcc dot gnu dot org 2008-10-22 11:33 ---
Created an attachment (id=16526)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16526&action=view)
gcc44-pr37878.patch
Just for the record, after discussions on IRC the bug was identified in
word_offset_memref_op
--- Comment #8 from earthengine at gmail dot com 2008-10-22 10:53 ---
Let me explain it more clearly.
Suppose I am building a toolchain to be running on a x86 Linux machine, and it
will generate code for mips Linux. With gcc 4.2.x, I can use
--host=i686-pc-linux-gnu --target=mips-linux
--- Comment #4 from hp at gcc dot gnu dot org 2008-10-22 10:50 ---
I'm not sure why this is suddenly a P5.
I'm unassigning myself, as Richard Sandiford has the ball (thank you again for
your effort) and is in progress of fixing the target prerequisites for de facto
the first part of the
--- Comment #7 from earthengine at gmail dot com 2008-10-22 10:31 ---
Hi, We have found the reason of this problem. The GCC 4.3+ serials can
automaticaly detect the --build parameter (i686-pc-linux-gnu, or something like
that). However, the previous version will use --host parameter if i
--- Comment #2 from jakub at gcc dot gnu dot org 2008-10-22 10:17 ---
Indeed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned a
Hi,
I'm trying to ask a new feature for gcc rater than reporting bugs now...
Missing this feature is more pressing on flash type microcontroller platforms
like (more and more types of) low pin count ARM core (ARM7, Cortex-M3),
Atmel/AVR and similars. However, more or less all the embedded area i
--- Comment #27 from manu at gcc dot gnu dot org 2008-10-22 08:35 ---
(In reply to comment #5)
> Note, however, that, as far as I can see, such try/catch are *not* in the
> library code proper, but *all* synthesized by the C++ front-end.
Does anyone has any idea where in the C++ front-e
--- Comment #28 from toon at moene dot indiv dot nluug dot nl 2008-10-22
08:28 ---
Jerry, do you think your patch can be applied and this bug closed ?
As I wrote, it fixed the original problem from which I constructed the two test
cases.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
88 matches
Mail list logo
