RE: GCC 4.5.1 Released (2)
Ik zie ook wat leuke dingen in de release notes: * MIPS targets now support the -fstack-protector option. Uit de handleiding: -fstack-protector Emit extra code to check for buffer overflows, such as stack smashing attacks. This is done by adding a guard variable to functions with vulnerable objects. This includes functions that call alloca, and functions with buffers larger than 8 bytes. The guards are initialized when a function is entered and then checked when the function exits. If a guard check fails, an error message is printed and the program exits. -fstack-protector-all Like '-fstack-protector' except that all functions are protected. -Original Message- From: gcc-announce-ow...@gcc.gnu.org [mailto:gcc-announce-ow...@gcc.gnu.org] On Behalf Of Richard Guenther Sent: Sunday, August 08, 2010 10:47 AM To: gcc-annou...@gcc.gnu.org Cc: gcc@gcc.gnu.org Subject: GCC 4.5.1 Released The GNU Compiler Collection version 4.5.1 has been released. GCC 4.5.1 is a bug-fix release containing fixes for regressions and serious bugs in GCC 4.5.0. This release is available from the FTP servers listed at: http://www.gnu.org/order/ftp.html Please do not contact me directly regarding questions or comments about this release. Instead, use the resources available from http://gcc.gnu.org. As always, a vast number of people contributed to this GCC release -- far too many to thank individually!
Re: [Bulk] Re: x86 assembler syntax
Tim,
Nice. It reads: "3.2.3. Intel syntax - Good news are that starting from
binutils 2.10 release, GAS supports Intel syntax too. It can be
triggered with .intel_syntax directive. Unfortunately this mode is not
documented (yet?) in the official binutils manual, so if you want to use
it, try to examine http://www.lxhp.in-berlin.de/lhpas86.html, which is
an extract from AMD 64bit port of binutils 2.11."
I tried a sample with asm(".intel_syntax; int 3") and it seemed to
compile/assemble that line correctly, instead of asm("int $0x3"). But
my other AT&T syntax commands all failed after that. So, this directive
must be a global setting, and not an instance-by-instance setting.
Thanks for the search, Tim. :-)
- Rick
On Sun, 2010-08-08 at 23:37 -0700, Tim Prince wrote:
> On 8/8/2010 10:21 PM, Rick C. Hodgin wrote:
> > All,
> >
> > Is there an Intel-syntax compatible option for GCC or G++? And if not,
> > why not? It's so much cleaner than AT&T's.
> >
> > - Rick C. Hodgin
> >
> >
> >
> I don't know how you get along without a search engine. What about
> http://tldp.org/HOWTO/Assembly-HOWTO/gas.html ?
>
Re: some integer undefined behaviors in gcc
On 08/09/10 08:42, John Regehr wrote: On Sat, 7 Aug 2010, Florian Weimer wrote: I wonder if we should give up and make -fwrapv the default. My sense is that there are not that many of these integer bugs, and probably all of them are simple to fix. Best to just fix them and then run a tool like ours every now and then to see if anything new has popped up. Really interesting: where can we read more about the tool? -- Prof. Roberto Bagnara Applied Formal Methods Laboratory Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:bagn...@cs.unipr.it
Re: some integer undefined behaviors in gcc
On Mon, 9 Aug 2010, John Regehr wrote: > On Sat, 7 Aug 2010, Florian Weimer wrote: > > I wonder if we should give up and make -fwrapv the default. > > My sense is that there are not that many of these integer bugs, and probably > all of them are simple to fix. Best to just fix them and then run a tool like > ours every now and then to see if anything new has popped up. GCC is of course meant to be written in C (or in future C++) and support being built with non-GNU C (or C++) compilers, rather than being written in C-with-wrapv, so these bugs should be fixed as part of making the code correct C or C++. Apart from the signed overflow undefined behavior bugs, there are also unsigned overflow bugs in memory allocations - none of the macros such as XNEWVEC, or places where the size of an allocation is calculated directly, check for overlow in calculating the size. (See gnulib for examples of allocation functions and macros that do have these checks.) -- Joseph S. Myers jos...@codesourcery.com
define_peepholes in mn10300
Hi Jeff,
I'm looking at the remaining text peepholes (define_peephole instead
of define_peephole2) and I have a few questions about mn10300, that
you are a maintainer of.
The first peephole is this:
;; Try to combine consecutive updates of the stack pointer (or any
;; other register for that matter).
(define_peephole
[(set (match_operand:SI 0 "register_operand" "=dxay")
(plus:SI (match_dup 0)
(match_operand 1 "const_int_operand" "")))
(set (match_dup 0)
(plus:SI (match_dup 0)
(match_operand 2 "const_int_operand" "")))]
""
"*
{
operands[1] = GEN_INT (INTVAL (operands[2]) + INTVAL (operands[1]));
return \"add %1,%0\";
}"
[(set_attr "cc" "clobber")])
It seems to me that we have the CSA pass for this
(combine-stack-adj.c). Maybe not for the "or any other register" part,
but that should never happen anyway, or one of the CSE passes has not
done its job properly. The peephole appears to pre-date the CSA pass.
I would like to eliminate this define_peephole. Do you agree? If so,
what would be sufficient testing for you to accept a patch that
removes this peephole?
The second question is about the remaining define_peepholes, that all
look more-or-less alike. Here is the first one:
(define_peephole
[(set (cc0) (compare (match_operand:SI 0 "register_operand" "dx")
(const_int 0)))
(set (pc) (if_then_else (ge (cc0) (const_int 0))
(match_operand 1 "" "")
(pc)))]
"dead_or_set_p (ins1, operands[0]) && REG_OK_FOR_INDEX_P (operands[0])"
"add %0,%0\;bcc %1"
[(set_attr "cc" "clobber")])
As far as I understand, the REG_OK_FOR_INDEX_P check is redundant:
* The constraints "dx" require a data register or an extended register
* REG_OK_FOR_INDEX_P(X) during peephoel is equivalent to
REGNO_STRICT_OK_FOR_INDEX_P(X,REG_STRICT)
* REGNO_STRICT_OK_FOR_INDEX_P requires REGNO_DATA_P or REGNO_EXTENDED_P.
So the constrains should already make sure that REG_OK_FOR_INDEX_P is valid.
Am I missing something?
I would like to convert these remaining define_peepholes to
define_peephole2s instead. However, I can't find a define_insn that
produces the bcs or bcc instructions. Could use a little help figuring
out what insn I should generate in the peephole2.
Thanks for any help you can give,
Ciao!
Steven
Link error
Dear all,
I am trying to build cross compiler for xc16x. I built successfully
binutils 2.18; gcc 4.0 and newlib 1.18. Everything is fine when
compiling a simple C file without any library call. It is also fine
when making a simple call to printf like printf("Hello world").
However, i got error message from linker when call printf("i=%i",i);
The error message is as follows
/home/guest/xc16x/lib/gcc/xc16x-elf/lib/xc16xl/libc.a(lib_a-sbrkr.o):
In function _sbrk_r:
/home/guest/newlib-1.18.0/newlib/libc/reent/sbrkr.c:60: undefined
reference to __sbrk
/home/guest/fromKpit/newlib-1.18.0/newlib/libc/reent/sbrkr.c:60:
undefined reference to __sbrk
collect2: ld returned 1 exit status
make: *** [bubble.out] Error 1
Is there any idea how to solve the problem? I highly appreciate any help.
Best regards,
Phung
Re: CALL_USED_REGISTERS per function basis
Hi, I am thinking (as I am not familiar with IRA) to the following alternative to your solution: I set to zero all CALL_USED_REGISTERS (except the fixed regs), and then in the expand_call I set CALL_INSN_FUNCTION_USAGE to the list of clobbered registers (given by attribute attached to a function declaration). Then, I should be able to achieve the same effect without touching the IRA. Additionally, a global variable will hold the "default" call_used_registers for the cases when the function call used regs attribute is not set. What do you think about this approach? Best regards, Claudiu
Semantics of PARALLEL that sets and uses CC0
Hello,
Forgive me if I overlooked it, but I can't find in the manuals what
the semantics would be of the following define_expand, from avr.md:
(define_expand "cbranchsi4"
[(parallel [(set (cc0)
(compare (match_operand:SI 1 "register_operand" "")
(match_operand:SI 2 "nonmemory_operand" "")))
(clobber (match_scratch:QI 4 ""))])
(set (pc)
(if_then_else
(match_operator 0 "ordered_comparison_operator" [(cc0)
(const_int 0)])
(label_ref (match_operand 3 "" ""))
(pc)))]
"")
The expander performs a SET of CC0 in the first pattern inside the
PARALLEL, and there is a USE of CC0 in the second pattern of the
PARALLEL.
The manual says this about PARALLELs:
//QUOTE//
``In parallel'' means that first all the values used in the individual
side-effects are computed, and second all the actual side-effects are
performed. For example,
@smallexample
(parallel [(set (reg:SI 1) (mem:SI (reg:SI 1)))
(set (mem:SI (reg:SI 1)) (reg:SI 1))])
@end smallexample
@noindent
says unambiguously that the values of hard register 1 and the memory
location addressed by it are interchanged. In both places where
@code{(reg:SI 1)} appears as a memory address it refers to the value
in register 1 @emph{before} the execution of the insn.
//QUOTE//
Applied to the AVR expander, this seems to indicate that the USE of
CC0 refers to the value of CC0 *before* the SET of CC0 in the first
pattern of the PARALLEL. But I think the intent of the expander is to
use the result of the compare. What am I missing?
This was coded by Paolo in r147425:
147425bonzini (define_expand "cbranchsi4"
147425bonzini [(parallel [(set (cc0)
147425bonzini (compare (match_operand:SI 1
"register_operand" "")
147425bonzini (match_operand:SI 2
"nonmemory_operand" "")))
147425bonzini (clobber (match_scratch:QI 4 ""))])
147425bonzini(set (pc)
147425bonzini (if_then_else
147425bonzini (match_operator 0
"ordered_comparison_operator" [(cc0)
147425bonzini
(const_int 0)])
147425bonzini (label_ref (match_operand 3 "" ""))
147425bonzini
Paolo, this wouldn't be my first stupid question about RTL, but I
don't understand this expander :-)
Help?
Ciao!
Steven
Re: Semantics of PARALLEL that sets and uses CC0
Steven Bosscher wrote: > Forgive me if I overlooked it, but I can't find in the manuals what > the semantics would be of the following define_expand, from avr.md: > > (define_expand "cbranchsi4" > [(parallel [(set (cc0) >(compare (match_operand:SI 1 "register_operand" "") > (match_operand:SI 2 "nonmemory_operand" ""))) > (clobber (match_scratch:QI 4 ""))]) >(set (pc) > (if_then_else > (match_operator 0 "ordered_comparison_operator" [(cc0) >(const_int 0)]) > (label_ref (match_operand 3 "" "")) > (pc)))] > "") > > The expander performs a SET of CC0 in the first pattern inside the > PARALLEL, and there is a USE of CC0 in the second pattern of the > PARALLEL. That's incorrect; the second pattern of the PARALLEL is just a CLOBBER. The USE of CC0 happens in a completely separate second INSN that is emitted by this define_expand. (Note that as opposed to define_insn, define_expand can emit more than a single insn.) Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE ulrich.weig...@de.ibm.com
Re: Semantics of PARALLEL that sets and uses CC0
On 08/09/2010 01:39 PM, Ulrich Weigand wrote: (define_expand "cbranchsi4" [(parallel [(set (cc0) (compare (match_operand:SI 1 "register_operand" "") (match_operand:SI 2 "nonmemory_operand" ""))) (clobber (match_scratch:QI 4 ""))]) (set (pc) (if_then_else (match_operator 0 "ordered_comparison_operator" [(cc0) (const_int 0)]) (label_ref (match_operand 3 "" "")) (pc)))] "") [...] the second pattern of the PARALLEL is just a CLOBBER. The USE of CC0 happens in a completely separate second INSN that is emitted by this define_expand. (Note that as opposed to define_insn, define_expand can emit more than a single insn.) Yeah, that's the case. What my patch did was just to combine the PARALLEL that the old cmpsi patterns produced (cc0 set), and the SET of the old bCC patterns (cc0 use). In fact, having a cc0 set not _followed_ by a cc0 use would totally break every other RTL pass. Paolo
Re: Semantics of PARALLEL that sets and uses CC0
On Mon, Aug 9, 2010 at 7:39 PM, Ulrich Weigand wrote: > That's incorrect; the second pattern of the PARALLEL is just a CLOBBER. Ah, parse error :-) Thanks for your help! Ciao! Steven
Re: define_peepholes in mn10300
On 08/09/2010 06:28 AM, Steven Bosscher wrote: > I would like to convert these remaining define_peepholes to > define_peephole2s instead. However, I can't find a define_insn that > produces the bcs or bcc instructions. Could use a little help figuring > out what insn I should generate in the peephole2. A normal branch with GEU produces bcc; LTU produces bcs. See %[Bb] in print_operand. r~
Re: CALL_USED_REGISTERS per function basis
On 08/09/2010 07:20 AM, Claudiu Zissulescu wrote: > I set to zero all CALL_USED_REGISTERS (except the fixed regs), and > then in the expand_call I set CALL_INSN_FUNCTION_USAGE to the list of > clobbered registers (given by attribute attached to a function > declaration). Then, I should be able to achieve the same effect > without touching the IRA. CALL_INSN_FUNCTION_USAGE says nothing about what registers are clobbered, only that they are *used* by the callee. I.e. they are arguments, either from the user via the declaration of the function or implicit via the ABI. Note that in some ABIs, function arguments may be in call-saved registers. Which implies that the register containing that function argument is unchanged after the call. So I don't see that this is the same effect at all. r~
BUILT_IN_FRONTEND - how did this work?
Hello, It seems that there once was support for builtin functions defined by a front end. This is still a useful idea (see e.g. PR24777) but it looks like there are no frontend built-in functions anymore. At least, a grep for BUILT_IN_FRONTEND gives no meaningful results. There's a hint that it may have worked, long ago, in ChangeLog-2000. But there is no documentation whatsoever about how BUILT_IN_FRONTEND is supposed to work. Does anyone know how BUILT_IN_FRONTEND should work, what one has to do to define a front-end built-in function? Examples? Any idea if there ever was a front end that used this feature? Ciao! Steven
Re: [Bulk] Re: x86 assembler syntax
On 9 August 2010 08:08, Rick C. Hodgin wrote:
> Tim,
>
> Nice. It reads: "3.2.3. Intel syntax - Good news are that starting from
> binutils 2.10 release, GAS supports Intel syntax too. It can be
> triggered with .intel_syntax directive. Unfortunately this mode is not
> documented (yet?) in the official binutils manual, so if you want to use
> it, try to examine http://www.lxhp.in-berlin.de/lhpas86.html, which is
> an extract from AMD 64bit port of binutils 2.11."
2.11 is quite old now
http://sourceware.org/binutils/docs-2.20/as/i386_002dDependent.html
> I tried a sample with asm(".intel_syntax; int 3") and it seemed to
> compile/assemble that line correctly, instead of asm("int $0x3"). But
> my other AT&T syntax commands all failed after that. So, this directive
> must be a global setting, and not an instance-by-instance setting.
http://sourceware.org/binutils/docs-2.20/as/i386_002dSyntax.html
Remove "asssertions" support from libcpp
Hi Tom, Assertions in libcpp have been deprecated since r135264: 2008-05-13 Tom Tromey PR preprocessor/22168: * expr.c (eval_token): Warn for use of assertions. Can this feature be removed for GCC 4.6? Ciao! Steven
