Hello.
At compiling gcc-4.3.0 with ../gcc-4.3.0/./configure prefix=/I get this
error:
--
...
checking whether the target asssembler upports thread-local storage... yes
updating cache ./config.cache
configure: creating ./config.status
config.status: creating Makefile
conf
The patch looks good. Please test and ask for approval to
commit to trunk on [EMAIL PROTECTED]
Thanks,
Sebastian
Here is a patch from Dwarak for fixing this.
He will send this to review on gcc-patches@ list.
Sebastian Pop
--
AMD - GNU Tools
--- Makefile.in 2008-10-23 10:33:51.274495000 -0500
+++ Makefile.in.fix 2008-11-19 16:11:55.80298 -0600
@@ -903,8 +903,9 @@ BUILD_LIBDEPS=3D $(BUILD_LIBIBERTY
ported first: this fails in the
debug dumps function. Could you report the backtrace using the following
flags:
gfortran -O3 -ftree-vectorize -ftree-parallelize-loops=2 -c ma57.f
Thank you,
Sebastian
Thanks for catching the missing parts.
Here is the updated patch. Does this patch look correct?
I sent this patch to test on the gccfarm and will send an email to
gcc-patches after it completes regstrap.
Thanks,
Sebastian
On Tue, Nov 25, 2008 at 5:08 PM, ghazi at gcc dot gnu dot org
<[EM
On Fri, Nov 28, 2008 at 3:38 AM, jakub at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
> The patch looks good to me (if not obvious). Sebastian, are you going to post
> it to gcc-patches?
I just sent it to gcc-patches.
Sorry this took me so long to send: it went out of my radar.
Sebastian
nt.cgi?id=16880&action=view)
> Updated patch reviewed by Sebastian
This looks better thanks. Ok for graphite branch.
t the result.
But this should be fixed now by the patch for PR38559.
Sebastian
at you
reported failing:
./cp2k.sopt canonical.inp
CP2K: The specified file canonical.inp can not be opened, it does not exist.
STOP 1
Could you tell me where I can find the canonical.inp file, or how to
reproduce the fail?
Thanks,
Sebastian
) output of change_bond_length function, and I suspect
that this is a global variable whose value is needed elsewhere outside
the change_bond_length function.
The bug is in the detection of scalar reductions.
Sebastian
2
Description: Binary data
Attached a fix for this PR. I will regstrap and submit for review.
Sebastian
2009-01-14 Sebastian Pop
PR middle-end/38431
* graphite.c (get_vdef_before_scop, scop_adjust_vphi): New.
(scop_adjust_phis_for_liveouts): Call scop_adjust_vphi.
(gloog): Do not call cleanup_tree_cfg
aphite.exp that could supply it either.
> Is this the intended behavior or is there something missing in this test (and
> possibly other graphite ones)?
The test for loop blocking is missing in block-3.c. We will have to
clean up the graphite testsuite and making the tests more reliable,
but probably this will be done in GCC4.5.
Sebastian
Hi,
Thanks for this report. Please also test with the code of graphite
branch that contains a
patch that schedules several scalar optimizations that can improve the
quality of the code generated.
Thanks,
Sebastian Pop
--
AMD - GNU Tools
> + /* Increase the limit by the PHI argument number to avoid exponential
> + time and memory complexity. */
This looks good.
Thanks,
Sebastian
What changed from 4.4 to 4.5 is that we now get to compile larger
SCoPs with Graphite. In 4.5, Graphite can deal with reductions and
other unhandled constructs like the NE_EXPR that Fortran is frequently
using for representing the exit condition of DO loops.
f gcc/objc/objc-act.c
Sebastian
> --- Comment #7 from grosser at gcc dot gnu dot org 2008-09-29 13:14
> ---
> Committed SVN 140746.
I see that in http://gcc.gnu.org/viewcvs?view=rev&revision=140746
you forgot to include in the changelog a line like this:
PR tree-optimization/37372
that would have automatically includ
The patch looks good. Please install.
I also have installed a similar patch in htdocs/gcc-4.4/changes.html
Here is a patch that should fix this bug. Can somebody test that it fixes it?
Thanks,
Sebastian
Index: tree-loop-linear.c
===
--- tree-loop-linear.c (revision 140668)
+++ tree-loop-linear.c (working copy)
@@ -333,11 +333,16
> 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
> It seems PLUS_EXPR and POINTER_PLUS_EXPR can really handled identically.
> So I will like to commit this patch.
Yes they should be handled in the same way in this context.
Please install the patch.
Thanks,
Sebastian
_assert by returning "unknown scalar evolution".
The second part of the bug was already fixed:
> aermod.f90:8312: internal compiler error: in expand_scalar_variables_expr, at
> graphite.c:3168
I will apply the patch below once it finishes regstrap.
Sebastian
Inde
Hi,
Can you try this patch. It should fix your problem. I will bootstrap
and test the
patch and send it for review.
Thanks,
Sebastian Pop
--
AMD - GNU Tools
On Thu, Feb 26, 2009 at 13:46, il dot basso dot buffo at gmail dot com
wrote:
>
>
> --- Comment #9 from il dot basso dot
(int) ivtmp.25_2;
# VUSE { SMT.10 SMT.11 }
D.1617_15 = *in_47;
# SMT.10_30 = VDEF
@@ -116,7 +123,7 @@
out_16 = out_48 + 1;
in_17 = in_47 + 1;
i_18 = i_49 + 1;
-if (num_comp_14(D) > i_18)
+if (ivtmp.25_2 < D.1654_4)
Thanks for the reduced testcase, it completely went out of my radar
(by now my delta script should have finished reducing it as well on
the gcc-farm, but I won't even look at it).
Thanks again for the reduced case. I will look at the bug now.
Sebastian
data reference
analysis.
I'm testing the patch on the gcc farm, and will send it to the gcc-patches
once it finishes regstrap.
Sebastian
* graphite.c (exclude_component_ref): Renamed contains_component_ref_p.
(is_simple_operand): Call contains_component_ref_p before calling data
reference ana
Awesome! Thanks Li, the patch looks good. Tobias will take care
of including it to the graphite branch.
Sebastian
Could you run gdb and report the backtrace?
# gdb build-gcc/gcc/cc1
(gdb) run -O3 -floop-strip-mine ... aes.i
(gdb) bt
Thanks,
Sebastian
On Fri, Oct 23, 2009 at 14:46, spop at gcc dot gnu dot org
wrote:
> and the code generated by CLooG for the interchange looks like this:
>
> for (scat_1=0;scat_1<=2;scat_1++) {
> for (scat_3=0;scat_3<=2;scat_3++) {
> S4(scat_1,scat_3) ;
> for (scat_5=0;scat_5<=2;scat_5++) {
> S5(scat_1
We do bootstrap on amd64-linux the graphite branch for every
commit, and that would be the equivalent of your patch.
Please open a new bug for tracking this issue.
Thanks,
Sebastian
Here is the loop kernel from block-0.c
for (i = 0; i < N; i++)
for (j = 0; j < N; j++)
a[j] = a[i] + 1;
On Fri, Dec 31, 2010 at 06:01, jakub at gcc dot gnu.org
wrote:
> access_fn_A: {0, +, 1}_1
> access_fn_B: {0, +, 1}_2
>
> (subscript
> iterations_that_access_an_element_twice_in
>> access_fn_A: {0, +, 1}_1
>> access_fn_B: {0, +, 1}_2
>>
>> (subscript
>> iterations_that_access_an_element_twice_in_A: [0 + 1 * x_1]
>> last_conflict: 1000
>> iterations_that_access_an_element_twice_in_B: [0 + 1 * x_1]
>
> I think that this representation of affine functions is wrong:
> th
On Fri, Feb 4, 2011 at 00:27, dirtyepic at gentoo dot org
wrote:
> I'm guessing that means 4.5 will stay broken?
>
Depends on how difficult it would be to backport the fix.
I haven't git-bisect'ed it to know which of the patches fixed it.
On Wed, Feb 10, 2010 at 12:26, amonakov at gcc dot gnu dot org
wrote:
> I don't see how this patch makes simple_iv call from number_of_iterations_exit
> return true for j_20. Could you please kindly explain?
We used to analyze the second scop after the code generation of the
first one. In that
> Well it could be vectorized even without range splitting. The issue is the
> "sinking" of the store to a[i].
You mean that the problem is the if-conversion of the stores
"a[i] = ..."
On Sat, Mar 20, 2010 at 05:45, dominiq at lps dot ens dot fr wrote:
> Do you understand why graphite does not detect that the loop for [scat_1+1,
> T_10-2] depends on the one for [0, scat_1-1]?
Graphite does know this, but it does not ask CLooG to generate
[0, scat_1-1] after [scat_1+1, T_10-2],
On Wed, Mar 24, 2010 at 16:35, howarth at nitro dot med dot uc dot edu
wrote:
>> Fixed.
>>
>> Please use ftp://gcc.gnu.org/pub/gcc/infrastructure/cloog-ppl-0.15.9.tar.gz
>>
>
> Shouldn't the required cloog-ppl version in configure be bumped from 0.15.5 to
> 0.15.9?
>
Richi what do you think?
On Mon, Apr 5, 2010 at 04:47, rguenth at gcc dot gnu dot org
wrote:
> You shouldn't be using type_for_size but instead use
> build_nonstandard_integer_type.
I copied this from another LNO pass, should I also update that pass?
What about this patch?
Seb
On Mon, Apr 5, 2010 at 22:16, spop at gcc dot gnu dot org
wrote:
> URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157977
> Log:
> Use build_nonstandard_integer_type.
This commit seems to create problems both in chrec_convert and in the
niter estimations: these use unsigned_type_for and sig
b hard limit on darwin. One
> solution could be to replace 1 with 4000. Also the following patch works.
Please update the size of arrays.
Thanks,
Sebastian
> htab_hash_pointer is fine if a hash table is never traversed, or such
> traversal
> can't affect code generation. E.g. graphite has some debug_* routines that
> traverse such hash tables, that's fine, they aren't called at all during
> compilation except for debugging sessions.
Ok, thanks for
> Ok, I have that fixed locally at the place of the patch but I wonder if
> initial_condition () shouldn't return for example
>
> 1ul for (unsigned long) { 1, +, 1 }_1
>
This is correct.
> and
>
> (int) i_2 for (int) { i_2, +, 1 }_1
>
> and further (for short i_2)
>
> i_2 for (short) { (int) {
be to rename all the scev info based on the
rename_map that is computed by the translation of the first scop.
I am working on a patch to do that.
Sebastian
On Fri, Nov 5, 2010 at 11:26, hjl.tools at gmail dot com
wrote:
> On trunk, it was fixed by revision 163123:
>
> http://gcc.gnu.org/ml/gcc-cvs/2010-08/msg00334.html
>
Thanks HJ for reducing this.
I looked at this change and it looks simple enough to backport it to 4.5.
Here is the backported patch that fixes the ICE.
I will further test this and will post to gcc-patches.
Sebastian
From 8f0cc975c09d2e0779f7e25a82a295f3deb9de46 Mon Sep 17 00:00:00 2001
From: Sebastian Pop
Date: Fri, 5 Nov 2010 13:15:25 -0500
Subject: [PATCH] Fix PR45314: backport revision 163123
These previous patches don't seem to solve the problem:
here is another reduced case that still fails in resolve_equivalence
at a different place than before.
$ cat bug.f
CALL TRFWTM(JKT,XX,NX,Y,NIX,NORB2,1,TOL)
IF(DBUG.AND.NX.GT.0) THEN
EQUIVALENCE (DBUGME, DBUGME_STR)
Patch http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00344.html
> Sebastian, that was your change.
http://gcc.gnu.org/viewcvs?view=rev&revision=135672
was a clean-up of the lambda framework.
I'm working on a fix.
Fix attached: that's a bad typo. This also fixes PR36286.
Sent to regstrap on gccfarm. I will commit it just after it passes.
Sebastian
email: [EMAIL PROTECTED]
branch:trunk
revision:HEAD
configure:
make:
check:
2008-05-21 Sebastian Pop <[EMAIL PROTECTED]>
PR tree-optimiz
--- Comment #17 from sebastian dot redl at getdesigned dot at 2009-01-07
21:14 ---
I have no idea how a prepended member can change the negative offset of the
other struct members. If I did, the bug wouldn't be there.
Is wrapping the struct in another struct the best way to e
Priority: P3
Component: libgomp
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebastian dot schlingmann at web dot de
GCC host triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38935
--- Comment #3 from sebastian dot redl at getdesigned dot at 2009-06-02
18:45 ---
Curiously enough, N2857 doesn't even require that exception_ptr be usable in
conditions. I must have simply assumed that anything with _ptr in its name must
be a valid condition.
So yeah, if the AB
--- Comment #4 from sebastian dot forsman at gmail dot com 2006-08-15
15:46 ---
I have exactly the same problem (and errors) on Debian 3.0 (kernel v2.4.28)
with gcc v2.95, make v3.79.1 and glibc v2.2.5.
Used the following simple configure: './configure --enable-threads=posix
--e
--- Comment #5 from sebastian dot forsman at gmail dot com 2006-08-15
17:09 ---
Ok "fixed" with:
mkdir mybuild
cd mybuild
../gcc-4.1.1/configure --enable-threads=posix --enable-languages=c,c++,java
make bootstrap
make install
Pierre you probably tried to configure/make dir
--- Comment #9 from sebastian dot wenzler at hp dot com 2009-04-16 06:40
---
I had the same problem with Solaris 10 on sparcv9 with gcc-4.3.3.
Environment:
1) binutils/2.15 2) bison/1.875 3) automake/1.4-p5 4) gcc/4.2.4
LD_RUN_PATH=/local/scratch/xhpsewe/424-64bit/lib
ct: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebastian dot bw at freenet dot de
GCC build triplet: i686-pc-linux-gnu
GCC host trip
ReportedBy: sebastian dot huber at embedded-brains dot de
GCC build triplet: *
GCC host triplet: *
GCC target triplet: m68k-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39784
--- Comment #1 from sebastian dot huber at embedded-brains dot de
2009-04-16 10:02 ---
Created an attachment (id=17648)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17648&action=view)
Proposal for trunk
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39784
--- Comment #15 from sebastian dot huber at embedded-brains dot de
2009-10-12 11:36 ---
(In reply to comment #13)
> Thanks for clarifying the !eh_personality_libfunc requirement. I'll do some
> experiments to see which solution works best in 4.4.
>
Is the target milesto
ncs.asm" broken for THUMB
version 1 since r150545
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
R
--- Comment #1 from sebastian dot huber at embedded-brains dot de
2009-10-21 09:30 ---
Created an attachment (id=18852)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18852&action=view)
Fix proposal
This works at least for me.
--
http://gcc.gnu.org/bugzilla/show_bug
--- Comment #2 from sebastian dot huber at embedded-brains dot de
2009-10-26 10:22 ---
Target: arm-elf
Configured with: /home/sh/gcc-4.5-20091015/configure
--prefix=/opt/tool-chain-elf --target=arm-elf --verbose --with-gnu-as
--with-gnu-ld --enable-languages=c
Thread model: single
gcc
IRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Sebastian at SSpaeth dot de
Target Milestone: ---
TL;DR:
This looks like a compiler bug or quality-of-implementation issue, and happens
JUST ON PPC with gcc. F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107745
--- Comment #2 from Sebastian "spaetz" Spaeth ---
(sid_ppc64el-dchroot)~$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/powerpc64le-linux-gnu/12/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARG
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107745
--- Comment #5 from Sebastian "spaetz" Spaeth ---
I fully understand that nobody wants to invest time into fixing this. What
would be nice though, is if this were really just a missed optimization and not
rejecting to compile
++
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebastian dot huber at embedded-brains dot de
http://gcc.gnu.org
--- Comment #1 from sebastian dot huber at embedded-brains dot de
2010-04-22 14:25 ---
Created an attachment (id=20463)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20463&action=view)
Example how to implement it
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43852
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebastian dot huber at embedded-brains dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43863
--- Comment #1 from sebastian dot huber at embedded-brains dot de
2010-04-23 06:55 ---
Created an attachment (id=20468)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20468&action=view)
Proposed changes.
An alternative is to define this class in a separate file.
--
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebastian dot huber at embedded-brains dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43865
--- Comment #1 from sebastian dot huber at embedded-brains dot de
2010-04-23 09:14 ---
Created an attachment (id=20470)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20470&action=view)
Compile errors from above "$ make -i".
--
http://gcc.gnu.org/bugzill
--- Comment #4 from sebastian dot huber at embedded-brains dot de
2010-04-23 09:16 ---
Bug report for 1. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43863.
Bug report for 2. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43865
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43852
--- Comment #5 from sebastian dot huber at embedded-brains dot de
2010-04-23 09:20 ---
Created an attachment (id=20471)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20471&action=view)
Lets call it quiet.
Configure option may be --enable-quiet-cxx.
--
http://gcc.
--- Comment #3 from sebastian dot huber at embedded-brains dot de
2010-04-23 09:28 ---
(In reply to comment #2)
> In Bug 43852 I thought you meant building with -fno-exceptions fails, but it
> works for me ... do you just mean the resulting library is not as small as it
>
--- Comment #6 from sebastian dot huber at embedded-brains dot de
2010-04-23 10:59 ---
(In reply to comment #5)
> Simply removing this class now would break the ABI, which is not acceptable.
> If Bug 43852 was resolved by adding a "quiet" mode, would that make th
--- Comment #3 from sebastian dot huber at embedded-brains dot de
2009-12-04 12:15 ---
The problem is still present with:
arm-elf-gcc (GCC) 4.5.0 20091203 (experimental)
--
sebastian dot huber at embedded-brains dot de changed:
What|Removed
--- Comment #5 from sebastian dot huber at embedded-brains dot de
2009-12-04 13:31 ---
This one works:
arm-elf-gcc (GCC) 4.4.3 20091201 (prerelease)
I think that r150545 introduced the problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41780
--- Comment #18 from sebastian dot huber at embedded-brains dot de
2010-08-12 08:19 ---
This bug is still present in GCC 4.6.0 20100807 (arm-eabi-gcc -O1
-fschedule-insns2 -mthumb):
readStream:
push{r4, lr}
sub sp, sp, #8
mov r4, sp
mov
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebastian dot huber at embedded-brains dot de
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GC
--- Comment #2 from sebastian dot huber at embedded-brains dot de
2010-09-10 15:43 ---
(In reply to comment #1)
> >1. index is constant or variable, and
>
> Yes that is correct.
>
> >2. the 'bar' field type.
>
> The alignment of the access is
--- Comment #4 from sebastian dot huber at embedded-brains dot de
2010-09-10 15:59 ---
(In reply to comment #3)
> >For volatile fields we should use accesses of the appropriate width.
>
> The PowerPC ABI has specific rules for accessing volatile bitfields and IIRC
>
dot org
ReportedBy: sebastian dot huber at embedded-brains dot de
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: arm-rtems4.10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44091
--- Comment #1 from sebastian dot huber at embedded-brains dot de
2010-05-12 07:21 ---
Created an attachment (id=20641)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20641&action=view)
Log.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44091
--- Comment #2 from sebastian dot huber at embedded-brains dot de
2010-05-12 07:21 ---
Created an attachment (id=20642)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20642&action=view)
Preprocessed source file.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44091
--- Comment #3 from sebastian dot huber at embedded-brains dot de
2010-05-12 07:22 ---
Created an attachment (id=20643)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20643&action=view)
Generated assembler file.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44091
--- Comment #4 from sebastian dot huber at embedded-brains dot de
2010-05-12 09:40 ---
GCC 4.5.0 20100414 has this problem too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44091
--- Comment #5 from sebastian dot huber at embedded-brains dot de
2010-05-12 10:03 ---
GCC 4.2.4 does not have this problem.
Function epilogue:
.L672:
ldr r0, [r7, #4]
mov sp, r7
add sp, sp, #52
@ sp needed for prologue
pop {r4
--- Comment #6 from sebastian dot huber at embedded-brains dot de
2010-05-12 11:06 ---
If you use GCC 4.5.0 20100414 with '-march=armv7' '-mthumb' '-Os' the function
epilogue is also correct. It seems that this is a Thumb 1 problem.
--
http://gcc.gn
--- Comment #7 from sebastian dot huber at embedded-brains dot de
2010-05-12 11:13 ---
GCC 4.3.2 20080827 has this problem too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44091
--- Comment #8 from sebastian dot huber at embedded-brains dot de
2010-05-12 12:03 ---
A summary follows. Broken means bdbuf.i generates an invalid stack frame usage
sequence in a function epilogue. Works means that the corresponding area is
valid.
Flags: -march=armv5t -mthumb -Os
--- Comment #10 from sebastian dot huber at embedded-brains dot de
2010-05-13 09:42 ---
Binary search through trunk revisions yield:
r159321 BROKEN
r15 BROKEN
r14 BROKEN
r135000 BROKEN
r132500 BROKEN
r131024 BROKEN
r130512 BROKEN
r130256 BROKEN
r130128 BROKEN
r130064 BROKEN
--- Comment #11 from sebastian dot huber at embedded-brains dot de
2010-05-13 09:50 ---
Created an attachment (id=20654)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20654&action=view)
Difference between bdbuf.s in revsions 130051 and 130052
This clearly shows how th
--- Comment #14 from sebastian dot huber at embedded-brains dot de
2010-05-17 09:04 ---
This bug is present since r130052 which is related to:
http://gcc.gnu.org/ml/gcc-patches/2007-10/msg01814.html
If this is a generic bug or not is quite irrelevant since this is a very
serious bug
--- Comment #17 from sebastian dot huber at embedded-brains dot de
2010-06-10 07:13 ---
Thank you for your investigations. A special case fix is better than nothing.
I am not a GCC expert but it seems that this kind of bug appears quite
regularly on different platforms and all use
are coupled
Product: gcc
Version: 4.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebastian dot huber at embedded-brains dot de
http
--- Comment #2 from sebastian dot huber at embedded-brains dot de
2010-06-23 15:02 ---
(In reply to comment #1)
> (In reply to comment #0)
> > The std::bad_alloc definitions should be placed into a
> > separate file.
>
> IIUC that wouldn't work, is require
--- Comment #4 from sebastian dot huber at embedded-brains dot de
2010-06-23 15:20 ---
Created an attachment (id=20987)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20987&action=view)
Moves std::bad_alloc implementation into new file bad_alloc.cc
I don't know how t
--- Comment #7 from sebastian dot huber at embedded-brains dot de
2010-06-24 09:41 ---
Created an attachment (id=20993)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20993&action=view)
Implementation, configure and documentation
Is libstdc++-v3/doc/xml/manual/configure.
--- Comment #9 from sebastian dot huber at embedded-brains dot de
2010-06-24 10:09 ---
Created an attachment (id=20995)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20995&action=view)
Implementation, configure and documentation
Sorry, the config.h.in was
--- Comment #12 from sebastian dot huber at embedded-brains dot de
2010-06-24 12:49 ---
(In reply to comment #11)
[...]
> I'll get this and Bug 44647 done for 4.6.0
Please have a look at Bug 43863 also.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43852
1 - 100 of 182 matches
Mail list logo
