On Sun, May 13, 2012 at 11:58 PM, H.J. Lu wrote:
> On Sun, May 13, 2012 at 12:01 PM, Richard Guenther
> wrote:
>> On Sun, May 13, 2012 at 6:32 PM, H.J. Lu wrote:
>>> Hi,
>>>
>>> I am trying to optimize memory address for x32. X32 runs in 64-bit mode.
>>> 64-bit address is base + index * scale +
On Mon, May 14, 2012 at 4:26 AM, Geert Bosch wrote:
>
> On May 13, 2012, at 21:17, amyl...@spamcop.net wrote:
>> The expectation is wrap-around. Note that loop strenght reduction can
>> cause assumed wrap-around semantics in RTL for strictly conforming C input
>> where no such wrap-around is in e
Hello.
I'am developing an statement detector for c++ and I would like to
detect if an statement is expanded from macro.
Can I detect in ast tree if an statement is expanded code from macro?
Thanks.
Hi Alberto,
As far as I understand it you want to know if a statement was expanded
from a preprocessor macro, right?
This isn't possible. The preprocessor is a separate thing altogether and
I doubt any preprocessing information remains for the compiler proper to
deal with.
Cheers,
Paulo M
This information is incorrect.
GCC tracks macro expansion information since GCC 4.7, and it has been
further improved and enabled by default in GCC 4.8. See the option
ftrack-macro-expansion and the interface located in
libcpp/include/line-map.h.
If you have trouble understanding the interface, f
Thanks for correcting me Manuel.
I am just getting acquainted with GCC4.7, good to know that information
has been added.
Cheers,
Paulo Matos
On 14/05/12 10:07, Manuel López-Ibáñez wrote:
This information is incorrect.
GCC tracks macro expansion information since GCC 4.7, and it has been
fur
Został przekroczony limit przechowywania w skrzynce pocztowej.
Nie będą mogli wysyłać i odbierać nowe wiadomości do uaktualnieniem
e-mail kontyngent.
Skopiuj poniższy link i wypełnij formularz w celu aktualizacji konta.
https://docs.google.com/spreadsheet/viewform?formkey=dHhlZVdORm1lVjU2aXRJUFg
On Sun, May 13, 2012 at 10:24 PM, wrote:
> Quoting "H.J. Lu" :
>
>> What is the run-time result when overflow happens?
>
>
> Assuming you use a 32 bit unsigned base address, and the space beyond 4G
> is unmapped, you'll get a SEGV.
So, when used for load and store, "base + offset" with overflow/
This looks good. I just want to check one thing with you. In point 5
you state that unresolved secondary symbols have a zero value. Are
you implying that unresolved secondary symbols should not result in a
link or load-time error? If that's the case, you should also make it
clear that a second
Postovani,
Prvi centar koji svim pravnim i fizickim osobama omogucuje potpuno besplatno
prodaju svih vrsta nove i rabljene robe i usluga .
Svu svoju robu ili uslugu mozete odmah - vec danas potpuno besplatno prodavati
direktno iz svog poduzeca, obrta, gospodarstva po svojim cijenama
preko porta
On 05/12/12 06:00, Steven Bosscher wrote:
> * toplev.c (process_options): Fail for sjlj exceptions if the
> target machine
> has no casesi insn and no tablejump insn.
Looks good. How many targets have neither case/tablejump?
r~
I'm running into an ICE due to what looks like wrong register allocation, and
I'm trying to figure out where the problem lies. It shows up with today's GCC
(trunk). I haven't yet tried to narrow it down to a particular change.
It shows up in the pdp11 target, -O2. Not clear that this is pdp11
On Mon, May 14, 2012 at 4:23 PM, Richard Henderson wrote:
> On 05/12/12 06:00, Steven Bosscher wrote:
>> * toplev.c (process_options): Fail for sjlj exceptions if the
>> target machine
>> has no casesi insn and no tablejump insn.
>
> Looks good. How many targets have neither case/
How about stating that the behavior of
STB_SECONDARY symbols in areas not specified
by this proposal matches that of STB_WEAK?
For example, we may not want to go into
runtime details when an unresolved-hence-zero-valued
secondary reference (type STT_FUNC) is hit at runtime.
In such instances let
I've just merged cxx-conversion up to rev 187449.
Diego.
> -Original Message-
> From: generic-...@googlegroups.com [mailto:generic-
> a...@googlegroups.com] On Behalf Of Lowell, Randy
> Sent: 14 May 2012 07:12 PM
> To: generic-...@googlegroups.com; GCC Development; Binutils; GNU C
> Library; Ansari, Zia
> Subject: RE: Add STB_SECONDARY to gABI
>
Hi,
Support for the x32 psABI:
http://sites.google.com/site/x32abi/
is added in Linux kernel 3.4-rc1. X32 uses the ILP32 model for x86-64
instruction set with size of long and pointers == 4 bytes. X32 is
already supported in GCC 4.7.0 and binutils 2.22. I am now working
to integrate x32 suppo
On 05/14/2012 10:31 AM, H.J. Lu wrote:
> Hi,
>
> Support for the x32 psABI:
>
> http://sites.google.com/site/x32abi/
>
> is added in Linux kernel 3.4-rc1. X32 uses the ILP32 model for x86-64
> instruction set with size of long and pointers == 4 bytes. X32 is
> already supported in GCC 4.7.0 an
On Mon, May 14, 2012 at 10:34 AM, H. Peter Anvin wrote:
> On 05/14/2012 10:31 AM, H.J. Lu wrote:
>> Hi,
>>
>> Support for the x32 psABI:
>>
>> http://sites.google.com/site/x32abi/
>>
>> is added in Linux kernel 3.4-rc1. X32 uses the ILP32 model for x86-64
>> instruction set with size of long and
> -Original Message-
> From: generic-...@googlegroups.com [mailto:generic-
> a...@googlegroups.com] On Behalf Of Suprateeka R Hegde
> Sent: Monday, May 14, 2012 12:40 PM
> To: generic-...@googlegroups.com; 'GCC Development'; 'Binutils'; 'GNU C
> Library'; 'Ansari, Zia'
> Subject: RE: Add ST
> For rl78 there is a comment in gcc/config/rl78/rl78.h that suggests
> there should be a tablejump insn, but it's not there.
The only unconditional branches rl78 has are immediate and
register-indirect, i.e. "BR $label" and "BR AX".
> This is unfortunate because rl78 is a "#define DWARF2_UNWIND
On 05/14/12 12:59, DJ Delorie wrote:
>> > For rl78 there is a comment in gcc/config/rl78/rl78.h that suggests
>> > there should be a tablejump insn, but it's not there.
> The only unconditional branches rl78 has are immediate and
> register-indirect, i.e. "BR $label" and "BR AX".
>
The later is c
Hi,
currently, our software (www.lejos.org, build with a gcc 4.3.x based
arm-elf toolchain) manages to compare floats correctly most of the time.
But sometimes, the comparisons don't have the expected result.
Basically, comparisons behave non-deterministically.
We believe, that this is the result
On Mon, May 14, 2012 at 1:36 PM, Sven Köhler wrote:
> Hi,
>
> currently, our software (www.lejos.org, build with a gcc 4.3.x based
> arm-elf toolchain) manages to compare floats correctly most of the time.
> But sometimes, the comparisons don't have the expected result.
> Basically, comparisons be
Quoting James Dennett :
On Mon, May 14, 2012 at 1:36 PM, Sven Köhler wrote:
Hi,
Is gcc 4.3 still supported? Will there be release of gcc 4.3.7?
No. http://gcc.gnu.org/ describes GCC 4.5.x as the "oldest maintained
release series".
Of course, if he has the resources and willingness to d
Quoting paul_kon...@dell.com:
I'm running into an ICE due to what looks like wrong register
allocation, and I'm trying to figure out where the problem lies. It
shows up with today's GCC (trunk). I haven't yet tried to narrow
it down to a particular change.
It shows up in the pdp11 ta
Section 16.9 of the current gcc doc is as follows. It implies that the
fma pattern should/could be used on a machine that double rounds the
multiply add.
`fmam4'
Multiply operand 2 and operand 1, then add operand 3, storing the
result in operand 0. All operands must have mode m. This pa
Am 14.05.2012 23:01, schrieb James Dennett:
> On Mon, May 14, 2012 at 1:36 PM, Sven Köhler wrote:
>> Hi,
>>
>> currently, our software (www.lejos.org, build with a gcc 4.3.x based
>> arm-elf toolchain) manages to compare floats correctly most of the time.
>> But sometimes, the comparisons don't ha
This code warns (incorrectly, but that's a whole separate issue):
double foo(double a, double b)
{
bool option1_ok, option2_ok;
double option1, option2;
if (a == 0) {
option1_ok = false;
} else {
option1 = b;
option1_ok = true;
}
if (a == 1) {
option2_ok = false;
} el
On 5/14/2012 6:26 PM, Andy Lutomirski wrote:
This seems to defeat the purpose, and adding
#pragma GCC diagnostic ignored "-Wpragmas"
is a little gross. How am I supposed to do this?
The gcc mailing list is for gcc development, not
quetions about the use of gcc, please address such
questions t
Kenneth Zadeck writes:
> Should i change the section 16.9 doc to indicate that this pattern is
> only to be used if the machine can do this with a single rounding?
Sure.
Ian
committed in revision 187494.
thanks.
On 05/14/2012 08:05 PM, Ian Lance Taylor wrote:
Kenneth Zadeck writes:
Should i change the section 16.9 doc to indicate that this pattern is
only to be used if the machine can do this with a single rounding?
Sure.
Ian
Hi,
Why can't we replace function force_expr_to_var_cost directly with function
computation_cost in tree-ssa-loop-ivopt.c?
Actually I think it is inaccurate for the current recursive algorithm in
force_expr_to_var_cost to estimate expr cost. Instead computation_cost can
count some back-end factor
33 matches
Mail list logo
