Re: [help-texinfo] Re: small font in gcc online docs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, Nov 03, 2008 at 01:00:31PM -, Jonathan Grant wrote: > Hello Karl, [...] > Perhaps GCC could use @example rather than @smallexample ? [lurker's opinion here, so take with appropriate amount of salt] I concur with Karl here. It's the combination of your browser and the stylesheet who decide how small a @smallexample ends up. It doesn't make much sense taking visibility at the abstract document level, since it's a property of the rendering medium and the user. You can easily set the minimum font size on your firefox, somewhere under edit->preferences->Content->Fonts->Advanced (or thereabouts -- don't you love GUI apps?). Regards - -- tomas -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFJD+kmBcgs9XrR2kYRAngqAJ44Oe3FOU4nzFLFrptR20CwrH5ZWgCffLe1 DZ0MPqK4gSISZ+nJaS2K66U= =LqDG -END PGP SIGNATURE-
http://gcc.gnu.org/svnwrite.html points to non-existing source http://gcc.gnu.org/ml/gcc-SVN/
Hi, I found out that page http://gcc.gnu.org/svnwrite.html points to http://gcc.gnu.org/ml/gcc-SVN/ mailing list but it doesn't exist. It's in section "Write access policies" above "Free for all" subsection. It seems that correct list is http://gcc.gnu.org/ml/gcc-cvs/. Tomas
Assignment form
Hi, I am working on some gcc patches (now profiling indirect/virtual calls and it's devirtualization) and i would like to contribute it to gcc. I've read that i must sign some forms for contributing. Could you tell me where can i get it ? Thanks Tomas Bily
Help with compiling pdf manual
Hi,
I tryed to compile manul to pdf format but I completely stuck. When I
run 'make pdf' it ends with error report:
invoke.texi:1250: I can't find file `'.
@begingroup
@value ->@begingroup
@makevalueexpandable @valuexxx
@temp ->@input @value
{srcdir}/../libiberty/at-file.texi
@includezzz ...mp [EMAIL PROTECTED] #1 [EMAIL PROTECTED] [EMAIL PROTECTED]
@popthisfilestack
l.1250 [EMAIL PROTECTED]/../libiberty/at-file.texi
Please type another input file name:
Line 1250 in invoke.texi looks like: @include
@value{srcdir}/../libiberty/at-file.texi
It seems that @value{srcdir} after @include is not expanded (though). I
found in archives that this problem was found few years ago
(http://gcc.gnu.org/ml/gcc-patches/2005-10/msg00609.html) and problem
was solved by checking if it is installed makeinfo >= 4.8. I am using
4.9. It seems that all other manual targets (html, info ...) work ok.
Do you have any recomendations for me ?
Greetings
Tomas
ps. I checked pdf version of manual on webpages
(http://gcc.gnu.org/onlinedocs/gccint.pdf) and I looked at page where
is @include ... included (page 25 bottom) and there is some mess.
error compiling libgcc with ported cross-compiler
I am porting gcc to a new target architecture, and have come across a
problem when the make process tries to compile libgcc. The error I get
is included below.
It seems that gcc has emitted rtl describing a memory reference (mem
(plus (mem (plus (reg ..) (const_int ..))) (const_int ..))), which
should not have been permitted by GO_IF_LEGITIMATE_ADDRESS since it
only allows (mem (plus (reg ..) (const ..))), and forbids a second
level of memory reference.
I am (obviously) no gcc-expert by far, and have no idea how to tackle
this problem. Has anyone had a similar problem, or any pointers as to
how I can solve it?
The error message is:
/cygdrive/c/home/risc/src/gcc-4.1.2/gcc/libgcc2.c: In function '__powidf2':
/cygdrive/c/home/risc/src/gcc-4.1.2/gcc/libgcc2.c:1559: error: insn
does not satisfy its constraints:
(insn 114 153 117
/cygdrive/c/home/risc/src/gcc-4.1.2/gcc/libgcc2.c:1558 (set
(mem/c/i:SI (plus:SI (mem/f/c:SI (plus:SI (reg/f:SI 29 r29)
(const_int -52 [0xffcc])) [0 D.2153+0 S4 A8])
(const_int 4 [0x4])) [0 +4 S4 A8])
(reg:SI 1 r1)) 3 {*movsi_internal} (nil)
(nil))
/cygdrive/c/home/risc/src/gcc-4.1.2/gcc/libgcc2.c:1559: internal
compiler error: in final_scan_insn, at final.c:2410
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
make[3]: *** [libgcc/./_powidf2.o] Error 1
make[3]: Leaving directory `/cygdrive/c/home/risc/build/gcc/gcc'
Re: error compiling libgcc with ported cross-compiler
On 9/10/07, Rask Ingemann Lambertsen <[EMAIL PROTECTED]> wrote:
>It would help a lot if you post your GO_IF_LEGITIMATE_ADDRESS.
It's really very basic:
# define GO_IF_LEGITIMATE_ADDRESS(MODE, X, ADDR) \
{ if (legitimate_address_p (MODE, X, true)) goto ADDR; }
and in the .c-file:
bool
legitimate_address_p (enum machine_mode mode, rtx addr, bool strict
ATTRIBUTE_UNUSED)
{
return (legitimate_offset_address_p (mode, addr)
|| legitimate_nonoffset_address_p (mode, addr));
}
static bool
legitimate_nonoffset_address_p (enum machine_mode mode
ATTRIBUTE_UNUSED, rtx addr)
{
return (GET_CODE (addr) == REG && REG_OK_FOR_BASE_P (addr));
}
static bool
legitimate_offset_address_p (enum machine_mode mode ATTRIBUTE_UNUSED, rtx addr)
{
rtx reg, offset;
if (GET_CODE (addr) != PLUS)
return false;
reg = XEXP (addr, 0);
offset = XEXP (addr, 1);
if ((GET_CODE (reg) == REG && REG_OK_FOR_BASE_P (reg))
&& legitimate_address_integer_p (offset, 0))
return true;
return false;
}
static bool
legitimate_address_integer_p (rtx addr, int offset ATTRIBUTE_UNUSED)
{
return (GET_CODE (addr) == CONST_INT
&& SMALL_INT (INTVAL (addr));
}
/Tomas
Re: error compiling libgcc with ported cross-compiler
Thanks a lot for your input, I think I understand some of that code better now.
I stumbled upon a solution last night, on realizing that the problem
was with the DFmode powidf2 and seeing that I had not defined the
movsf or movdf insns (because I thought I shouldn't need them, having
no HW floating point support).
Defining them solved the problem, but now I have a very similar one
with the complex arithmetic __mulsc3 function in libgcc:
/cygdrive/c/home/risc/src/gcc-4.1.2/gcc/libgcc2.c:1702: error: insn
does not satisfy its constraints:
(insn 1468 1467 1471
/cygdrive/c/home/risc/src/gcc-4.1.2/gcc/libgcc2.c:1701 (set
(mem/c/i:SF (plus:SI (mem/f/c:SI (plus:SI (reg/f:SI 29 r29)
(const_int -296 [0xfed8])) [0 D.2393+0 S4 A8])
(const_int 4 [0x4])) [0 +4 S4 A8])
(reg:SF 0 r0 [orig:51 D.2338+4 ] [51])) 8 {movsf} (nil)
(nil))
This time I'm not sure what to do though. Do I really have to define
complex movsc-insns? I haven't found any other ports doing that, so
I'm guessing there's something else I'm missing.
support for float/complex math in libgcc cross-compiled
(I'm turning this into a thread of it's own, it's really the
continuation of "error compiling libgcc with ported cross-compiler"
from yesterday.)
I am porting GCC to a new target, and got the following error when
cross-compiling libgcc towards the end of the make process:
/cygdrive/c/home/risc/src/gcc-4.1.2/gcc/libgcc2.c:1702: error: insn
does not satisfy its constraints:
(insn 1468 1467 1471
/cygdrive/c/home/risc/src/gcc-4.1.2/gcc/libgcc2.c:1701 (set
(mem/c/i:SF (plus:SI (mem/f/c:SI (plus:SI (reg/f:SI 29 r29)
(const_int -296 [0xfed8])) [0 D.2393+0 S4 A8])
(const_int 4 [0x4])) [0 +4 S4 A8])
(reg:SF 0 r0 [orig:51 D.2338+4 ] [51])) 8 {movsf} (nil)
(nil))
I had a very similar problem some days ago, in the __powidf2 function,
and then the solution was to define the movsf insn.
This time I'm not sure what to do though. The problem now seems to be
with complex number, but do I really have to define complex
movsc-insns? I haven't found any other ports doing that, so I'm
guessing there's something else I'm missing.
What is really needed in terms of insns or target macros to support
the various types of math of libgcc? Am I missing some insn for moving
from SFmode to SImode?
Re: error compiling libgcc with ported cross-compiler
On 9/11/07, Rask Ingemann Lambertsen <[EMAIL PROTECTED]> wrote: > On Tue, Sep 11, 2007 at 08:52:38AM +0200, Tomas Svensson wrote: >You shouldn't define them, they'll only hide the problem. You're right, and getting REG_OK_STRICT right solved the problem! That was probably the best answer I have ever gotten to any question I've asked online, by the way. Thank you very much for taking your time!
porting problem: segfault when compiling programs that call malloc
I am porting gcc to a new architecture, and have yet another problem that I've been staring at for far too long now. Whenever I compile a program that calls malloc, GCC crashes with: /cygdrive/c/home/risc/src/gcc-4.1.2/gcc/unwind-dw2-fde.c: In function '__register_frame': /cygdrive/c/home/risc/src/gcc-4.1.2/gcc/unwind-dw2-fde.c:119: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. make[3]: *** [libgcc/./unwind-dw2-fde.o] Error 1 (this example is from compiling libgcc, but the exact same thing happens for any file that calls malloc). I've looked at it in gdb and the error occurs in expand_call() in gcc/calls.c, at line 2787: rtx temp = gen_reg_rtx (GET_MODE (valreg)); where valreg is a null pointer. I've looked at the source, but I really can't see why it would be anything other than zero at that point, so I don't understand what is causing this. Does anyone have an idea about where to look for the cause of the problem?
Re: porting problem: segfault when compiling programs that call malloc
On 13 Sep 2007 13:45:21 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: > valreg is set around line 2564 of calls.c. It shouldn't be zero at > line 2787. Unless you have an malloc function with a return type of > void, which seems dubious. Ok, do you have any idea about what might cause this to happen? Could it be something wrong with exception handling or dwarf2 debugging output? Or possibly varargs handling? I am complete lost here unfortunately... Other function calls work just fine.
porting problem again: ICE in add_clobbers
I am still porting gcc v4.1.2 to a new risc architecture, and this
time my problem is that when compiling with -O2 turned on, every insn
with a (use ..) side effect expression, eg.
(define_expand "sibcall"
[(parallel [(call (match_operand 0 "" "")
(match_operand 1 "" ""))
(use (match_operand 2 "" ""))
(use (match_operand 3 "" ""))])]
"TARGET_SIBCALL"
{
if (operands[3] == NULL_RTX)
operands[3] = const0_rtx;
internal_expand_sibcall (0, XEXP (operands[0], 0), operands[1]);
DONE;
})
causes the compiler to fail with an internal compiler error in add_clobbers.
I have looked at it in gdb and it fails on reaching the
gcc_unreachable() in add_clobbers, which happens because add_clobbers
is called (at combine.c:9576) with an insn_code_number that it does
not recognize.
Everything works fine when optimization is turned off. What is it that
gcc does differently when optimizing, that might cause this to happen?
Re: porting problem again: ICE in add_clobbers
I have investigated it further, and thought I'd add it to my question.
I have tried compiling with all optimization flags turned on manually
(list included below) and that compiles just fine. That leads me to
think that what is causing the bug is some undocumented optimization,
triggered only if optimize > 0. Unfortunately, this is checked for all
over the source, and I still have no idea where to start looking, so
if anyone recognizes this, please let me know!
My original question is included below. The optimization switches I've
turned on are:
-falign-functions -falign-jumps -falign-loops -falign-labels
-freorder-blocks -fdefer-pop -fdelayed-branch
-fguess-branch-probability -fcprop-registers -floop-optimize
-fif-conversion -fif-conversion2 -ftree-ccp -ftree-dce
-ftree-dominator-opts -ftree-dse -ftree-ter -ftree-lrs -ftree-sra
-ftree-copyrename -ftree-fre -ftree-ch -funit-at-a-time
-fmerge-constants -fthread-jumps -fcrossjumping
-foptimize-sibling-calls -fcse-follow-jumps -fcse-skip-blocks -fgcse
-fgcse-lm -fgcse-sm -fgcse-las -fexpensive-optimizations
-fstrength-reduce -frerun-cse-after-loop -frerun-loop-opt
-fcaller-saves -fpeephole2 -fschedule-insns -fschedule-insns2
-fsched-interblock -fsched-spec -fregmove -fstrict-aliasing
-fdelete-null-pointer-checks -freorder-functions -ftree-vrp -ftree-pre
-fomit-frame-pointer -fforce-mem
On 9/18/07, Tomas Svensson <[EMAIL PROTECTED]> wrote:
> I am still porting gcc v4.1.2 to a new risc architecture, and this
> time my problem is that when compiling with -O2 turned on, every insn
> with a (use ..) side effect expression, eg.
>
> (define_expand "sibcall"
> [(parallel [(call (match_operand 0 "" "")
> (match_operand 1 "" ""))
> (use (match_operand 2 "" ""))
> (use (match_operand 3 "" ""))])]
> "TARGET_SIBCALL"
> {
> if (operands[3] == NULL_RTX)
> operands[3] = const0_rtx;
>
> internal_expand_sibcall (0, XEXP (operands[0], 0), operands[1]);
> DONE;
> })
>
> causes the compiler to fail with an internal compiler error in add_clobbers.
>
> I have looked at it in gdb and it fails on reaching the
> gcc_unreachable() in add_clobbers, which happens because add_clobbers
> is called (at combine.c:9576) with an insn_code_number that it does
> not recognize.
>
> Everything works fine when optimization is turned off. What is it that
> gcc does differently when optimizing, that might cause this to happen?
>
Re: porting problem again: ICE in add_clobbers
On 9/18/07, Jim Wilson <[EMAIL PROTECTED]> wrote: > Tomas Svensson wrote: > There is no optimization at all without -O, no matter how many -f > options you use. What you want to do is -O -fno-foo -fno-bar etc. > However, we do not have -f options for every optimization, so there is > no guarantee that this will identify the optimization pass that exposes > the bug in your port. Right, thanks. I sure hope I learn from all these silly mistakes... Anyway, I did the same thing again, this time with starting with the -O2 that causes the problem and turning off options with -fno- flags. This time, I found the compilation to work with '-O2 -fno-gcse' but to break with just '-O2'. So I guess the problem is somehow caused by global common subexpression elimination. Could it be that gcse changes the insn in some way, making it unrecognizable by the usual define_insn's? Should I use (unspec ..) or (clobber ..) instead of (use ..) (as suggested in GCC Internals, Side effects)? If so, what is the difference, really?
Re: porting problem again: ICE in add_clobbers
On 19 Sep 2007 07:54:14 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: > gcse will never convert a recognizable insn into an unrecognizable > insn. Ok. Do you know of any other reasons why this particular optimization switch would cause this problem? > You still haven't showed us the actual insn which failed to match. > > The problem is that whatever that insn looks like, there is no > define_insn which matches it. For purposes of matching, a > define_expand does not count. One example is (define_expand "bleu" [(use (match_operand 0 "" ""))] "" "expand_branch (LEU, operands[0]); DONE;") which is heavily inspired by the or32 port of version 3.4.4, as is expand_branch(). But this should not need a matching insn, since it ends in a DONE;, right? Or am I missing something again?
specifying insn costs from attributes
In the .md-file of my port, I have set an attribute "size" of every insn, giving its size (obviously), in bytes. Is there any way I can use the value of this attribute to determine the cost (in e.g. TARGET_RTX_COSTS) when optimizing for size? Or is there some other smart way of achieving the same thing? Is it better to use the "length" attribute for this?
Re: [gnu.org #247501] Submitting to the Gnu Project
Hello, I filled and posted FSF assignment (with an employer disclaimer) back to FSF via mail half year ago. Did you received it ? Best Regards Tomas Bily > Hello, > > This email is to follow up on your communication with the Free Software > Foundation. Previously, you had expressed interest in contributing to > the GNU Project. If this is still the case please respond so that we > can move the process along. If you did not receive the assignment > please let us know and we will cheerfully mail out another. If you need > an employer disclaimer and did not receive one via email we will forward > you a copy. > > I apologize if this email reached you in error, but please let me know > so that I may remove you from the record. It too is possible that you > have completed your assignment process with the FSF, but have yet to be > removed from the list of outstanding assignments. If this is the case > please let me know so that I can update the record. > > > All the best, > Jonas Jacobson > Copyright Administrator > Free Software Foundation > 51 Franklin Street, Fifth Floor > Boston, MA 02110 > Phone +1-617-542-5942 > Fax +1-617-542-2652 >
Re: [gnu.org #247501] Submitting to the Gnu Project
Hi Gerald, > Tomas, > > On Mon, 2 Jan 2006, Tomas Bily via RT wrote: > > I filled and posted FSF assignment (with an employer disclaimer) back > > to FSF via mail half year ago. Did you received it ? > > I found the following in the copyright file on the FSF network: > > GCC Tomas Bily United States 2005-07-28 > Assigns past and future changes > [EMAIL PROTECTED] > > ANY SuSe Prague 2005-07-26 > Disclaims all past interest and for 5 years from the date of the > disclaimer, in changes made to free software by Tomas Bily. > > The country appears to be wrong (since I believe you are Czech, not > American), but apart from that everything looks okay (for the next > 4.5) years. Yes, i am czech :). > (I removed you year of birth and replaced it with "" above.) > > Gerald > > > Tomas
Unexpected behavior of gcc on pointer dereference & increment
Hi, I recently discovered that the following C statement: pointer++; is semantically equivalent to the following: *pointer++; Is this due to operators' priority? To me, that looks weird. Thanks in advance, Tomas
Re: [musl] GCC optimizer is provably junk. Here is the evidence.
On 2024-03-24 13:20:36 -0500, Dave Blanchard wrote: > Here's a nice gem from Julian Waters, a thoroughly pleasant and amiable > fellow: > > > Hello again, Dave. Have you managed to learn how a basic language > > Interpreter works before commenting on the significantly-more-complex > > gcc's efficiency? Or were you not able to because your IQ is below the > > freezing point of water and you can't even understand what a basic > > tree walker is? > > > Then again, with an address like killthe.net, why should we even take > > you seriously? Hell, even though I miraculously agree that stuff like > > GNU and Linux is not beginner friendly, and gcc could do with some > > improvements in that department, no one wants to take any advice from > > a self righteous and idiotic piece of shit like yourself. At least > > Stefan was smart enough to bail when others pointed out the holes in > > his examples of gcc's instruction selection allegedly being poor. You, > > not so much. I doubt the clang people want you either, so do them a > > favour and stay the hell away from LLVM, and this is coming from > > someone who doesn't really like LLVM in the first place. > Since this message seems to be in violation of GCC's code of conduct, I assume you brought that up. What was the conclusion of that? If you did not, why not? > In my view, the entire GNU organization is a toxic cancer on the UNIX > world...and it was designed to be exactly that from the very beginning. > > It appears the true purpose of GNU was to "embrace, extend, extinguish" the > fledgling UNIX open source world; to capture and control it with sinister and > selfish motives and intentions; exactly the same strategy as Microsoft has > famously used elsewhere, and exactly the same as RedHat along with Linux > Puttering and their ilk have continued today. When one understands this, and a > lot of things that don't make any sense will suddenly become clear. > This is quite severe accusation, one that does not really seem to be based in much facts. Regardless of what you think of GNU software regarding bloat and some other choices, we collectively own the movement much for advancing the cause of free software in the original UNIX landscape full of proprietary tools. -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors. signature.asc Description: PGP signature
