when it is practical (or rather, allow dpkg-buildflags to
enable it).
Thanks,
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
signature.asc
Description: Digital signature
Couldn't get registers: Device or resource busy.
| (gdb) quit
| A debugging session is active.
|
| Inferior 1 [process 95320] will be detached.
|
| Quit anyway? (y or n) [answered Y; input not from terminal]
| Detaching from program: , process 95320
| ptrace: Device or resource busy.
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
signature.asc
Description: Digital signature
set $value4 = --(varl)
| | down
| | set xvalue = $value1
| | set unavailable = $value1 != $value2 ? -1 : $value3 != $value4 ? 1
: 0
| | continue
| |"
pid 85526 is seen telling gdb to attach to pid 85526. That seems odd,
but I think that really is intended.
Thanks,
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
signature.asc
Description: Digital signature
Steven Chamberlain wrote:
> Christoph Egger wrote:
> > | WARNING: 30 signals -- adjust and recompile.
>
> That comes from pkill, which recently stopped working. This means, the
> build already hung / timed out and sbuild is merely failing to kill it.
The warning messages
ll fails, number_of_signals changed
I still need to find out why the gcc-6/-snapshot builds hang.
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
signature.asc
Description: Digital signature
will look into this problem ASAP but maybe those builds can be marked as
'Failed' so that other packages build in the meantime?
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
signature.asc
Description: Digital signature
Package: src:gcc-5
Version: 5.4.0-2
Severity: important
Tags: patch
Hi,
Part of ada-kfreebsd.diff has been applied upstream. The Debian 5.4.0-2
package defines function clock_getres again, causing it to FTBFS.
| s-osinte.ads:223:13: "clock_getres" conflicts with declaration at line 218
| s-osin
Package: gnat-4.9
Version: 4.9.3-3
Severity: important
Hi,
In gnat-4.9's debian/control file there is an empty field:
Build-Depends-Indep:
Is this intentional? Perhaps it should not be there at all.
I can't see that this is prohibited by policy, but it seems to be a
problem for `apt-get buil
/main/g/gcc-5
What happened to 5.3.1-6? It seems to be still listed in debian/control
so I don't think it was removed/decrufted on purpose?
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
signature.asc
Description: Digital signature
Hi,
Svante Signell wrote:
> I think the same patch applies to the kfreebsd-* builds as well. Adding the
> kfreebsd usertag to this bug.
Thank you very much, Svante! The attached inter-diff against
ada-kfreebsd.diff fixes this for kfreebsd also.
Regards,
--
Steven Chamberla
Control: reassign -1 src:kfreebsd-kernel-headers
Control: tags -1 - moreinfo + pending
Steven Chamberlain wrote:
> The multilib files are actually in /usr/include/x86_64-kfreebsd-gnu, yet
> it is looking at /usr/include/i386-kfreebsd-gnu instead.
>
> I don't know if this was in
Control: tags -1 - patch + moreinfo
Matthias Klose wrote:
> On 08/31/2015 03:42 PM, Steven Chamberlain wrote:
> >> +
> >> +ifeq ($(DEB_TARGET_ARCH_OS),kfreebsd)
> >> + : # multilib builds without b-d on gcc-multilib (used in
> >> FLAGS_
al if someday linux kernel headers could move
too, and eventually multilib would become obsolete?
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
signature.asc
Description: Digital signature
Package: src:gcc-5
Version: 5.2.1-15
Severity: wishlist
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
Hi,
gcc-5 already supports having some linux kernel headers at
/usr/include/$(DEB_TARGET_MULTIARCH)/asm
We'd like to move *all* of kfreebsd-kernel-headers into
/usr/include/$(DEB_TA
nto ways to improve it.
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140927215115.ga23...@squeeze.pyro.eu.org
Makefile:466: recipe for target 'check-am' failed
> make[5]: *** [check-am] Error 2
> make[5]: Target 'check' not remade because of errors.
Oooh, I see. It's failing in the testsuite. I didn't run that yet.
(DEB_BUILD_OPTIONS='nocheck' because the
yet how to rebuild the control file, to get these
installed into a .deb, and I have no clue how to test it either.)
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5415cac6.3090...@pyro.eu.org
ce) all of
build-essential and perhaps other things.
Have fun!
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
signature.asc
Description: OpenPGP digital signature
ng.
Yes, that definitely should not be there. I may try another build this
weekend on a clean sid system, with that definition removed.
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54148376.3090...@pyro.eu.org
#5
Thanks,
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53ff5418.7050...@pyro.eu.org
On Fri, 25 Jul 2014 11:29:06 -0700
Linus Torvalds wrote:
> On Fri, Jul 25, 2014 at 7:02 AM, Steven Rostedt wrote:
> >
> > But wouldn't it be rather trivial to run a static analyzer on the final
> > vmlinux to make sure there are no red zones? I mean, you would
ready fixed this (though Debian's buildd systems
may not have been updated with it yet). If you are able to test with
that version and let us know, that would be wonderful.
Thank you,
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.d
On Fri, 25 Jul 2014 13:01:11 -0700
Linus Torvalds wrote:
> For example, gcc will not create a small stack frame with "sub
> $8,%rsp". No, what gcc does is to use a random "push" instruction.
> Fair enough, but that really makes things much harder to see. Here's
> an example:
>
> 81314
On Fri, 25 Jul 2014 11:29:06 -0700
Linus Torvalds wrote:
> On Fri, Jul 25, 2014 at 7:02 AM, Steven Rostedt wrote:
> >
> > But wouldn't it be rather trivial to run a static analyzer on the final
> > vmlinux to make sure there are no red zones? I mean, you would
On Thu, Jul 24, 2014 at 08:55:28PM -0700, Alexei Starovoitov wrote:
>
> -mno-red-zone only affected prologue emition in gcc. This part didn't
> change between the releases. So the bug is quite deep.
> What seems to be happening is that 2nd pass of instruction scheduler
> (after emit prologue and r
Hi,
On 24/05/14 22:42, Steven Chamberlain wrote:
> The issue with running the GCC testsuite on kfreebsd-amd64 buildds is
> being fixed by FreeBSD upstream, and on Debian buildds within 1-2 weeks.
Both of the kfreebsd-amd64 buildds have been patched for this issue now;
kfreebsd-i386
C 4.9 are
actually okay.
The issue with running the GCC testsuite on kfreebsd-amd64 buildds is
being fixed by FreeBSD upstream, and on Debian buildds within 1-2 weeks.
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55277
Steven Bosscher changed:
What|Removed |Added
Target|i486-linux-gnu |ix86-linux-gnu
--
Configure bugmail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55277
Steven Bosscher changed:
What|Removed |Added
Depends on|42536 |
--
Configure bugmail: http
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42536
Steven Bosscher changed:
What|Removed |Added
Blocks|55277 |
Summary|[4.6/4.7/4.8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55277
Steven Bosscher changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42536
Steven Bosscher changed:
What|Removed |Added
Blocks||55277
--
Configure bugmail: http
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40180
Steven Bosscher changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38642
Steven Bosscher changed:
What|Removed |Added
Status|WAITING |RESOLVED
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29206
Steven Bosscher changed:
What|Removed |Added
Status|WAITING |RESOLVED
CC
arch=kfreebsd-amd64&ver=2.0.0-2&stamp=1316362682
Therefore closing this bug. Thanks!
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.de
all files. This ensure that
# gtype.state is correctly read:
+ $(SHELL) $(srcdir)/../move-if-change tmp-gtype.state gtype.state
$(RUN_GEN) build/gengtype$(build_exeext) $(GENGTYPE_FLAGS) \
-r gtype.state
$(STAMP) s-gtype
Thanks,
Regards,
--
Steven Chamb
# http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53549#c13
tags 667341 + fixed-upstream
thanks
--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/500df6f2.7050...@pyro.eu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27453
Steven Bosscher changed:
What|Removed |Added
CC||steven at gcc dot gnu.org
--- Comment
Hi,
This bug prevents gcc-4.6 from migrating to testing with
important-severity bug fixes as peter explains:
http://lists.debian.org/4fe22188.9020...@p10link.net
Is it still the Release Team's wish to roll back the change at this late
stage?
Regards,
--
Steven Chamberlain
ste...@pyro.e
found 637236 4.6.3-7
thanks
Hi,
Just noting that this bug still happened recently. A consecutive
failure/success on the same buildd. Best keep an eye on it for a while
longer.
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
--
To UNSUBSCRIBE, email to debian-gcc-requ
tree-optimization/53438,
>PR target/52999, PR middle-end/53008.
Thanks,
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
maybe the same fixes will help if there's some future switch to LLVM/Clang.
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4fc36d56.2090...@pyro.eu.org
tags 673579 + patch
thanks
On 19/05/12 23:02, Christoph Egger wrote:
> Steven Chamberlain writes:
>> #if defined(__linux__) || defined(__GNU__) || defined(__GLIBC__)
>
> __GLIBC__ should cover all of them alone. Or alternatively consistently
> checking for kernels [...]
Oh
Hi Salvatore,
In src/ansi-c/c_preprocess.cpp, the #include changed by
KiBi's patch is still wrapped in #ifdef __linux__.
I would think:
#if defined(__linux__) || defined(__GNU__) || defined(__GLIBC__)
is the best way to cover Linux/kFreeBSD/Hurd.
Regards,
--
Steven Chamberlai
tags 673567 + patch
thanks
Hi,
Attached is a patch which will hopefully fix this on all the affected
architectures. Only tested this myself on kfreebsd-i386 though.
Thanks,
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
Description: fix to build with GCC 4.7
Must include where needed
> make[3]: Leaving directory
> `/build/buildd-qgis_1.7.4+1.7.5~20120320-1+b1-i386-O84wRU/qgis-1.7.4+1.7.5~20120320/debian/build'
> make[2]: *** [src/core/CMakeFiles/qgis_core.dir/all] Error 2
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
--
To UNSUBSCRIBE, email
Hi,
On 28/01/12 03:35, Steven Chamberlain wrote:
> $ g++-4.6 /usr/include/sys/soundcard.h
> In file included from /usr/include/machine/_types.h:8:0,
> from /usr/include/sys/_types.h:33,
> from /usr/include/machine-i386/endian.h:37,
>
--- Comment #16 from steven at gcc dot gnu dot org 2010-07-20 13:55 ---
May be a dup of 43494, based on comment #7.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35658
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
GCC target triplet||i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42536
--- Comment #10 from steven at gcc dot gnu dot org 2009-06-22 16:14 ---
Note that we usually add the name of the committer to the ChangeLog too, like
so:
2009-06-22 Steven Bosscher <...>
Matthias Klose <...>
etc.
But thanks for handling the patch. Fi
--- Comment #8 from steven at gcc dot gnu dot org 2009-06-22 08:12 ---
Re. Comment #5:
I have no plans to sumbit this patch. But do feel free to foster-parent it ;-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28050
--- You are receiving this mail because: ---
You are
--- Comment #9 from steven at gcc dot gnu dot org 2009-02-19 19:57 ---
*** Bug 39210 has been marked as a duplicate of this bug. ***
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from steven at gcc dot gnu dot org 2008-12-01 23:04 ---
With so many dups, IMHO this ought to be fixed for the releases...
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Keywords|ice-on-valid-code |wrong-debug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11654
--- Comment #5 from steven at gcc dot gnu dot org 2008-02-13 22:04 ---
I also can't reproduce it (neither on native nor with a cross).
Any local patches? Maybe you can reduce it to a set of simpler configuration
options?
--
steven at gcc dot gnu dot org changed:
--- Comment #8 from steven at gcc dot gnu dot org 2008-01-30 09:10 ---
How did you configure gcc (i.e. command line)? What is the output if you
compile with -v?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33410
--- You are receiving this mail because: ---
You reported
--- Comment #30 from steven at gcc dot gnu dot org 2008-01-12 00:25 ---
After playing with dbgcounts to see what happens, I indeed found the same as
what Eric notes in comment #27. The proposed fix makes perfect sense.
I won't be fixing this, I think Eric has already propose
--- Comment #26 from steven at gcc dot gnu dot org 2008-01-10 23:58 ---
Mark, wrt. the release, I recommend this PR shouldn't be a blocker. The
problem is old and is currently latent on the trunk, where it is only exposed
with non-default options (-fno-inline-small-func
--- Comment #25 from steven at gcc dot gnu dot org 2008-01-10 23:44 ---
So this has been failing since at least GCC 3.4. And I see nothing in the
identified patch that is related to how CSE handles its values, so I suspect
this bug exists in older compilers as well (just needs another
--- Comment #23 from steven at gcc dot gnu dot org 2008-01-10 22:18 ---
Created an attachment (id=14916)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14916&action=view)
new test case that fails before the tree-ssa merge
I made a new test case out of the .final_cleanup du
--- Comment #21 from steven at gcc dot gnu dot org 2008-01-09 22:46 ---
at cse.c:5418:
elt = insert (dest, sets[i].src_elt,
sets[i].dest_hash, GET_MODE (dest));
dest = (reg:DI 66 [ type.0+-4 ])
sets[i].src_elt->exp = (sign_extend:DI (reg:SI 72 [ t
--- Comment #20 from steven at gcc dot gnu dot org 2008-01-09 19:09 ---
I still haven't been able to reproduce it with a cross and with the original
test case. I'll try the reduced test case. Wish me luck. ;)
--
steven at gcc dot gnu dot org changed:
What
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW |SUSPENDED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29607
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW |SUSPENDED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29469
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #17 from steven at gcc dot gnu dot org 2008-01-08 16:14 ---
Does anyone know how to reproduce this with a cross-compiler?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31944
--- You are receiving this mail because: ---
You are on the CC list for the bug, or
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING |NEW
Last reconfirmed|2007-04-30 11:52:08 |2008-01-07 17:40
--- Comment #6 from steven at gcc dot gnu dot org 2007-12-27 15:28 ---
Actually, that df failure was due to a local patch. With a clean tree, a cross
from cygwin to alpha does not ICE.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33410
--- You are receiving this mail
--- Comment #5 from steven at gcc dot gnu dot org 2007-12-27 12:59 ---
Currently breaks with a df-verify error with a cross from i686-cygwin to
alpha-linux-gnu.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33410
--- You are receiving this mail because: ---
You reported
--- Comment #5 from steven at gcc dot gnu dot org 2007-12-18 23:31 ---
xf. http://gcc.gnu.org/ml/gcc-patches/2007-04/msg01789.html
I was wrong to object to this patch -- there really doesn't seem to be any
other way. It's funny, on the one hand we complain about the code
--- Comment #5 from steven at gcc dot gnu dot org 2007-12-18 20:34 ---
Martin, is this a bug you can still reproduce with the current SVN trunk? If
so, could you provide a backtrace from gdb?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29474
--- You are receiving this mail
--- Comment #3 from steven at gcc dot gnu dot org 2007-12-18 20:33 ---
Martin, is this a bug you can still reproduce with the current SVN trunk? If
so, could you provide a backtrace from gdb?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29472
--- You are receiving this mail
--- Comment #4 from steven at gcc dot gnu dot org 2007-12-18 20:29 ---
See http://gcc.gnu.org/ml/gcc-testresults/2007-10/msg01406.html for recent test
suite results. The first three failures are gone, as observed by Andreas too.
The largefile.c failures still exist. But as Andrew
--- Comment #8 from steven at gcc dot gnu dot org 2007-12-16 23:20 ---
Waiting for DR -> SUSPENDED.
--
steven at gcc dot gnu dot org changed:
What|Removed |Ad
--- Comment #12 from steven at gcc dot gnu dot org 2007-12-16 23:19 ---
If we are waiting for a DR, this PR should be SUSPENDED, not WAITING.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from steven at gcc dot gnu dot org 2007-12-05 22:29 ---
What does the full cse1 dump look like at that point (don't forget to call
fflush(dump_file) from gdb ;-) Is this reproducible with a cross-compiler?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=
--- Comment #8 from steven at gcc dot gnu dot org 2007-11-26 20:07 ---
.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING
--- Comment #3 from steven at gcc dot gnu dot org 2007-11-26 14:14 ---
flow.c is gone, so if this bug is still around in GCC 4.3, it's somewhere else
now. For released versions of GCC this won't be fixed.
If you still see a problem, please file a new bug report about it.
-
--- Comment #6 from steven at gcc dot gnu dot org 2007-11-26 14:12 ---
No test case, no progress. If this problem still exists, we need more than a
pointer to a build log to investigate the problem.
--
steven at gcc dot gnu dot org changed:
What|Removed
--- Comment #11 from steven at gcc dot gnu dot org 2007-11-14 10:00 ---
Is this still a problem?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30088
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
--
To
--- Comment #14 from steven at gcc dot gnu dot org 2007-11-10 16:40 ---
Patch is waiting for approval of the C++ bits.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from steven at gcc dot gnu dot org 2007-11-05 21:38 ---
It seems to me that a recursive function can never be safely treated as
const/pure. In fact, any function in an SCC in the call graph could result in
an endless loop and is therefore not const/pure. I'm assuming
--- Comment #3 from steven at gcc dot gnu dot org 2007-10-21 10:00 ---
The way for you to narrow down the bug is this:
1. Compile with -daAP
2. Look in the .s file which instruction references the missing label. There
should be a LABEL_REF with a number.
3. Grep for "code_label.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Component|middle-end |tree-optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30132
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
OtherBugsDependingO||33356
nThis||
http
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
CC|steven at gcc dot gnu dot |
|org |
http
On Wed, 08 Aug 2007 12:46:50 -0400, Steven Young wrote:
>>Fix:
> I don't know.
comp.gcc.bugs indicates undefined C99 behavior doesn't need a fix. =)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
>Submitter-Id: net
>Originator:Steven Young
>Organization: n/a
>Confidential: no
>Synopsis: gcc allows negatively-sized arrays
>Severity: non-critical
>Priority: low
>Category: c
>Class: accepts-illegal
>Release: gcc (GCC
--- Comment #4 from steven at gcc dot gnu dot org 2007-05-11 21:51 ---
There doesn't seem to be another way to get this to work, than the proposed way
with extra basic blocks. The things I've tried either break gcc, or gdb, or
debug info. Unassigning.
--
steven at gcc d
--- Comment #3 from steven at gcc dot gnu dot org 2007-04-30 12:01 ---
There are at least 2 issues here:
1) We just lose the locus of the goto statements when we lower GIMPLE and when
we jump across forwarded blocks.
2) When we don't lose the locus in GIMPLE, we lose it in cfge
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot
|dot org
--- Comment #8 from steven at gcc dot gnu dot org 2006-11-18 01:27 ---
Shouldn't this be fixed by Roger Sayle's recent fold-const.c patch?
--
steven at gcc dot gnu dot org changed:
What|Removed
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Summary|gcj should generate N_MAIN |gcc should allow gcj and
|stab or DW_AT_entry_point
--- Comment #19 from steven at gcc dot gnu dot org 2006-10-14 14:17 ---
Someone should make gdb understand the DW_AT_calling_convention attribute.
This is the bit necessary to make it work for Fortran. I considered stealing a
bit on FUNCTION_DECL to mark it as the main program but it
--- Comment #1 from steven at gcc dot gnu dot org 2006-09-25 15:04 ---
Either show that it is a regression, or dont put the regression marker in the
subject.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from steven at gcc dot gnu dot org 2006-08-02 21:10 ---
Happens when we are in find_if_case_1, where we call:
delete_basic_block (then_bb);
The basic block we try to remove is this one:
;; basic block 5, loop depth 1, count 0
;; prev block 9, next block 6
;; pred
--- Comment #7 from steven at gcc dot gnu dot org 2006-08-02 20:52 ---
;; Insn is not within a basic block
(code_label 48 47 49 11 "" [3 uses])
;; Insn is not within a basic block
(jump_insn 49 48 50 (addr_diff_vec:DI (label_ref:DI 48)
[
(label_
1 - 100 of 184 matches
Mail list logo
