On 15 Jan 2009, at 01:44, Ian Lance Taylor wrote:
I need to make a test expanded from ASM_OUTPUT_LABEL_REF that is
language dependent (on objc/objcxx).
It's pretty hard to think of any reason why something as low-level as
ASM_OUTPUT_LABEL_REF would want to look at anything in the frontend.
You
Ben Elliston wrote:
>> I cannot find where to download gcc binary for Linux. Can you email me
>> the link? It's so confusing in the http://gcc.gnu.org/ web site.
>
> You should install gcc from your Linux distribution. It will be far
> easier.
To add: There are no binaries of GCC released by the
IainS writes:
> 2/ assume that no sensible user will make an intention external symbol
> named ZL_OBJC_xx
>perhaps that's not too unreasonable... OBJC_x are effectively
> reserved identifiers - so perhaps mangled file scope variants of those
> could be too.
Symbols starting with
hi,
I am trying to output automata description by using -v flag , but it failed.
The option parsing code seems have a little bug?
It parse extra flags in initiate_automaton_gen, after init_md_reader_args.
9327 if (init_md_reader_args (argc, argv) != SUCCESS_EXIT_CODE)
9328return (FATAL_E
Tobias Burnus wrote:
>
> Otherwise, you could consider building GCC yourself, cf.
> http://gcc.gnu.org/install/. (Furthermore, some gfortran developers
> offer regular GCC builds, which are linked at
> http://gcc.gnu.org/wiki/GFortranBinaries; those are all unofficial
> builds, come without any w
Hi,
it seems that there's no "trivial.m" in gcc/testsuite/objc/execute
a copy of that in gcc/testsuite/objc/execute/exceptions would work
Iain.
#import
int main(void)
{
[Object class];
return 0;
}
On Thu, Jan 15, 2009 at 12:13 PM, IainS
wrote:
> Hi,
> it seems that there's no "trivial.m" in gcc/testsuite/objc/execute
Hmm, this is only needed if execute.exp is run only I think.
Thanks,
Andrew Pinski
On 15 Jan 2009, at 20:40, Andrew Pinski wrote:
On Thu, Jan 15, 2009 at 12:13 PM, IainS
wrote:
Hi,
it seems that there's no "trivial.m" in gcc/testsuite/objc/execute
Hmm, this is only needed if execute.exp is run only I think.
that's true, and generally it's not noticed otherwise.
That's
On Thu, Jan 15, 2009 at 12:51 PM, IainS
wrote:
> This doesn't seem quite right - because you get different results for
> "--target_board=unix\{-m32,-m64\} " and "--target_board=unix\{-m64,-m32\} "
You should not get different results with those options. At least on
any correct OS :). If you are
On 15 Jan 2009, at 20:57, Andrew Pinski wrote:
On Thu, Jan 15, 2009 at 12:51 PM, IainS
wrote:
This doesn't seem quite right - because you get different results for
"--target_board=unix\{-m32,-m64\} " and "--target_board=unix\{-
m64,-m32\} "
You should not get different results with those o
Dave Korn wrote:
> Sebastian Pop wrote:
>
> Hi Seb,
>
>>> Anyway, TIA for any enlightenment anyone can provide. I could file PRs or
>>> patches for the first two bugs if desired,
>> I would highly appreciate this.
>
> Righto, will get cracking.
You already posted a patch for the first one
Snapshot gcc-4.3-20090115 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20090115/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.3 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
> Now I just set v_flag to 1 manually in code to get the output, but I
> don't think it is a correct way.
> Anyone could tell me the correct way to output automata description,
> or help me to confirm this bug?
I don't think there is a bug. What do you have in your define_automaton
directive? No
struct s
{
char a:4;
char b:8;
char c:4;
} __attribute__ ((packed))
is 3 bytes long because b gets pushed to the next byte boundary.
You would think that similarly:
struct t
{
char a:4;
short b:16;
char c:4;
} __attribute__ ((packed))
would come out to be 4 bytes long. However, t
[ DJ Delorie Cc'd in as libiberty maintainer ]
Hi DJ,
We're having a bit of build trouble for GCC HEAD on Cygwin: to recap, ...
> Dave Korn wrote:
>> Andy Scott wrote:
>
>>> ../../../gcc/libiberty/strsignal.c -o strsignal.o
>>> ../../../gcc/libiberty/strsignal.c:408: error: conflicting typ
IIRC, that whole clause was because cygwin's dll itself linked with
libiberty, so the auto-detect stuff needed an override to make sure
the right files were there when you build cygwin1.dll. Otherwise, it
would detect that cygwin had strsignal, not build it, then fail later
when cygwin1.dll could
16 matches
Mail list logo
