setting a breakpoint on a break statement

[Tristan Gingold]

Hi,

in some cases, a breakpoint can't be set on a continue or break  
statement.  Here is a simple example:


void foc (void)
{
  int a, i;

  for (i = 1; i <= 10; i++) {
if (i < 3)
  a = 1;
else
  break; // line 9
a = 5;
  }
}

int main(void)
{
  foc ();
}

The reason is quiet simple: even at -O0 -g, there is no insn (and no  
BB) corresponding to the break/continue statement.

Here is a small patch which fixes the issue.
I wonder if this is the right approach.  This patch makes the code  
generated at -O0 uglier...


I think this issue has already been discussed, at least for gcc 3.4

Tristan.



bp.diff
Description: Binary data

Re: setting a breakpoint on a break statement

[Tristan Gingold]

On Mar 14, 2007, at 3:16 PM, Ian Lance Taylor wrote:


Tristan Gingold <[EMAIL PROTECTED]> writes:


in some cases, a breakpoint can't be set on a continue or break
statement.  Here is a simple example:



The reason is quiet simple: even at -O0 -g, there is no insn (and no
BB) corresponding to the break/continue statement.
Here is a small patch which fixes the issue.
I wonder if this is the right approach.  This patch makes the code
generated at -O0 uglier...


Thanks for sending the patch.  Procedural note: patches should be sent
to [EMAIL PROTECTED], and should have a ChangeLog entry.
Thank you for the procedure. I will follow it when I submit the patch  
formally



I don't think it is appropriate to change the meaning of
forwarder_block_p.  And I'm not sure why you need that patch anyhow,
considering the existing code in cleanup_tree_cfg_1.
Without that change, the rtl jump pass cleans the jump and all the  
previous work is useless.



Also you should ideally add a test case.
The effects are only visible for the debugger.  How to write a  
compiler test case for this case ?


Thanks,
Tristan.

Re: Bug 29609

[Tristan Gingold]

On Apr 26, 2007, at 3:07 PM, Claus Fischer wrote:



Dear GCC folks,

may I humbly put in a word for my dear bug 29609,
which is very close to my heart?

I write most of my C code in the style

if (!do_something(...))
goto failure_handler;

and letting the debugger stop at the 'goto' line is
quite important to finding bugs quickly.


Is there anything I can help or contribute?

I was working on this issue and the patch is almost ready!

Tristan.

Re: obsolete targets

[Tristan Gingold]

On 10 Jul 2014, at 04:23, Trevor Saunders  wrote:

> Hi,
> 
> I've noticed that the following targets are built in config-list.mk with
> --enable-obsolete
> i686-interix3 - doesn't appear to actually require --enable-obsolete
> though, should it be marked as obsolete in config.gcc?
> score-* and picochip-* since atleast sept 2012, is there a reason they
> haven't been removed yet?
> 
> Also I've noticed that all the vms targets in config-list.mk fail
> because they try to link vms-c.o into cc1plus, but a symbol needed by
> vms-c.o is only defined in cc1 (it has been this way since at least mid
> may).  Does anyone care about vms, or should we recognize what seems to
> be the state of afairs and mark it as obsolete?

For VMS, only the C compiler is supported (we know there are much more
difficult issues with stdc++).

Regards,
Tristan.

Re: Trouble trying to test GCC on a simulator

[Tristan Gingold]

On 08 Sep 2014, at 12:01, Pierre-Marie de Rodat  wrote:

> Hello,
> 
> I would like to test a GCC patch on the platform it is supposed to affect 
> (PowerPC). In order to to this, I'm using the following documentation:
> 
>https://gcc.gnu.org/simtest-howto.html
> 
> However, after fresh CVS checkouts (even without my changes on the GCC tree) 
> and the corresponding combined tree creation, I cannot manage to get a build:

CVS ?  Binutils (and gdb) are now using git:

If you plan to do active work on GNU binutils, you can access the development 
source tree by anonymous git:

  git clone git://sourceware.org/git/binutils-gdb.git

Tristan.

Re: Trouble trying to test GCC on a simulator

[Tristan Gingold]

On 08 Sep 2014, at 16:51, Pierre-Marie de Rodat  wrote:

> On 09/08/2014 12:26 PM, Tristan Gingold wrote:
>> CVS ?  Binutils (and gdb) are now using git:
> 
> Huh! I knew this, but not being a daily CVS user, I though the commands in 
> the documentation would get a binutils version that was somehow tailored for 
> GCC's needs. Anyway, here is what I just tried instead:
> 
># Get newlib and the simulator
>cvs -d :pserver:anon...@sourceware.org:/cvs/src co newlib sim

Note that sim is considered as part of gdb, so  ...

[..]

> It seems to work fine! (I'm running tests, now...) So thank you very much, 
> Tristan. I'm going to submit a website patch to update the documentation 
> according to this.

... you should use sim from binutils-gdb.git

Changing base compiler requirement for bootstrapping GNAT

[Tristan Gingold]

Is it ok to require gcc 4.9 (3 years old) or later to build GNAT ?

We plan to use gcc exceptions within the GNAT front-end (previously we were 
using a FE specific exception mechanism).
This requires a matching implementation in the runtime, which was last changed 
for gcc 4.9
Our idea is to completely remove in GNAT the support of the FE specific 
exception mechanism.

Is anyone opposed to such a change ?

Tristan.

Re: Changing base compiler requirement for bootstrapping GNAT

[Tristan Gingold]

> On 19 Jan 2017, at 11:46, Richard Biener  wrote:
> 
> On Thu, Jan 19, 2017 at 11:11 AM, Tristan Gingold  wrote:
>> Is it ok to require gcc 4.9 (3 years old) or later to build GNAT ?
>> 
>> We plan to use gcc exceptions within the GNAT front-end (previously we were 
>> using a FE specific exception mechanism).
>> This requires a matching implementation in the runtime, which was last 
>> changed for gcc 4.9
>> Our idea is to completely remove in GNAT the support of the FE specific 
>> exception mechanism.
>> 
>> Is anyone opposed to such a change ?
> 
> But as you are bootstrapping you should always have a matching
> runtime, no?

Yes for stage-2 and stage-3, but not always for stage-1.

To clarify: the gnat1 and gnatbind binaries are not linked with libgnat, but 
are built in a standalone way.  GNAT1_OBJS contains both the objects for the 
compiler sources and the objects for the needed runtime sources.
The compiler has some knowledge of the runtime (not unlike cc1plus or even 
cc1), so the runtime files used to built gnat1/gnatbind must be compatible with 
the base compiler.

>  That is, the built gnat1 will not use
> the host compilers runtime?

Yes, that's correct (unlike cc1plus which uses host libstdc++).

Tristan.

Re: Changing base compiler requirement for bootstrapping GNAT

[Tristan Gingold]

> On 19 Jan 2017, at 13:33, Jakub Jelinek  wrote:
> 
> On Thu, Jan 19, 2017 at 01:26:32PM +0100, Andreas Schwab wrote:
>> On Jan 19 2017, Tristan Gingold  wrote:
>> 
>>> Is it ok to require gcc 4.9 (3 years old) or later to build GNAT ?
>> 
>> The newest Ada compiler available for SLE11 is 4.8.
> 
> Various people still use 4.4 or even 4.1 as bootstrap compilers.
> While 3 years old requirement is way better than the Rust nonsense (only
> support bootstrap with 6 weeks older Rust and not older), it is still not
> good enough for GCC IMHO.

I was not able to build gnat with a gcc 4.1 compiler (looks to be too old),
but I think I can add compatibility stuff to be able to bootstrap with gcc-4.3
(which is 8 years old).

Tristan.

Re: Changing base compiler requirement for bootstrapping GNAT

[Tristan Gingold]

> On 19 Jan 2017, at 12:31, Richard Biener  wrote:
> 
> On Thu, Jan 19, 2017 at 12:04 PM, Tristan Gingold  wrote:
>> 
>>> On 19 Jan 2017, at 11:46, Richard Biener  wrote:
>>> 
>>> On Thu, Jan 19, 2017 at 11:11 AM, Tristan Gingold  
>>> wrote:
>>>> Is it ok to require gcc 4.9 (3 years old) or later to build GNAT ?
>>>> 
>>>> We plan to use gcc exceptions within the GNAT front-end (previously we 
>>>> were using a FE specific exception mechanism).
>>>> This requires a matching implementation in the runtime, which was last 
>>>> changed for gcc 4.9
>>>> Our idea is to completely remove in GNAT the support of the FE specific 
>>>> exception mechanism.
>>>> 
>>>> Is anyone opposed to such a change ?
>>> 
>>> But as you are bootstrapping you should always have a matching
>>> runtime, no?
>> 
>> Yes for stage-2 and stage-3, but not always for stage-1.
>> 
>> To clarify: the gnat1 and gnatbind binaries are not linked with libgnat, but 
>> are built in a standalone way.  GNAT1_OBJS contains both the objects for the 
>> compiler sources and the objects for the needed runtime sources.
> 
> Oh, I can see how that breaks then...  the stage1 gnat1/gnatbind
> should use the host Ada compiler runtime

That's a possibility we are also discussing, but it is much more difficult.
Maybe for later (Eric strongly supports that idea).

> (does bootstrapping GNAT with
> a non-GNAT Ada compiler work?  It really should!),

I could work on that if you (or someone else) gives me a non-GNAT Ada compiler 
for my machine :-)

Tristan.

Re: Changing base compiler requirement for bootstrapping GNAT

[Tristan Gingold]

> On 19 Jan 2017, at 13:33, Jakub Jelinek  wrote:
> 
> On Thu, Jan 19, 2017 at 01:26:32PM +0100, Andreas Schwab wrote:
>> On Jan 19 2017, Tristan Gingold  wrote:
>> 
>>> Is it ok to require gcc 4.9 (3 years old) or later to build GNAT ?
>> 
>> The newest Ada compiler available for SLE11 is 4.8.
> 
> Various people still use 4.4 or even 4.1 as bootstrap compilers.
> While 3 years old requirement is way better than the Rust nonsense (only
> support bootstrap with 6 weeks older Rust and not older), it is still not
> good enough for GCC IMHO.

For the record, we now have a plan to still allow gcc 4.1 as a bootstrap 
compiler.

Tristan.

Re: Revision 180821 breaks bootstrap

[Tristan Gingold]

On Nov 3, 2011, at 3:23 PM, Richard Guenther wrote:

> On Thu, Nov 3, 2011 at 3:22 PM, Richard Guenther
>  wrote:
>> On Thu, Nov 3, 2011 at 3:20 PM, Dominique Dhumieres  
>> wrote:
>>> Revision 180821 breaks bootstrap on x86_64-apple-darwin10:
>>> 
>>> ../../work/gcc/collect2.c: In function 'int main(int, char**)':
>>> ../../work/gcc/collect2.c:1094:7: error: unused variable 'object_nbr' 
>>> [-Werror=unused-variable]
>>> cc1plus: all warnings being treated as errors
>>> 
>>> Note that I did not find any entry for this revision in 
>>> gcc-patc...@gcc.gnu.org.
>> 
>> I suppuse on all non-AIX platforms even ...
> 
> Fixed as follows, committed as obvious.

One possible alternate fix is:

--- a/gcc/collect2.c
+++ b/gcc/collect2.c
@@ -1144,7 +1144,7 @@ main (int argc, char **argv)
   ld1 = CONST_CAST2 (const char **, char **, ld1_argv);
   ld2_argv = XCNEWVEC (char *, argc + 11);
   ld2 = CONST_CAST2 (const char **, char **, ld2_argv);
-  object_lst = XCNEWVEC (char *, argc);
+  object_lst = XCNEWVEC (char *, object_nbr);
   object = CONST_CAST2 (const char **, char **, object_lst);
 
 #ifdef DEBUG


Tell me if you prefer this one.

Sorry for the breakage.

Tristan.

Re: CVS/SVN binutils and gcc on MacOS X?

[Tristan Gingold]

On Sep 4, 2009, at 11:06 PM, Stefan Dösinger wrote:


Hi,
I tried to install binutils from CVS and the gcc SVN code on my mac  
to test my

msvc_prologue work there, but I ran into an interesting problem:

When using the SVN gcc with my own as, I cannot compile any files:
Assembler messages:
Fatal error: Invalid listing option `r'


The support in FSF binutils for Darwin is very preliminary: although  
the assembler passes all the gas tests,
it lacks many Mach-O features.  I am working on that in a low priority  
mode.


But contributions are welcome!

Tristan.

Re: apple blocks extension

[Tristan Gingold]

On Sep 15, 2009, at 3:46 PM, Steven Bosscher wrote:


Hi,

The status is that there is no status, unfortunately (it's an
interesting extension...).

This extension is not presently implemented in the FSF GCC.
AFAIU there is no reason to believe Apple will contribute patches to
implement it.


I think you may (are allowed to) port it from Apple GCC sources.

Tristan.

Re: Idea for Google Summer Code : C Compiler for EFI Byte Code implement in gcc

[Tristan Gingold]

On Mar 3, 2010, at 11:36 AM, Andrew Haley wrote:

> On 03/03/2010 04:52 AM, b95705...@ntu.edu.tw wrote:
> 
>> I am highly interestd in implementing C compiler for EFI Byte Code in
>> gcc and participate in Google Summer Code.
>> 
>> EFI is a much larger, more complex,OS-like replacement for the older BIOS
>> firmware interface present in all IBM PC-compatible personal computers.
>> and the EFI specification provides for a processor-independent device
>> driver environment(like virtualmachine), called EFI Byte Code or EBC.
>> 
>> Intel(R) C Compiler for EFI Byte Code, the only one C compiler for EFI
>> Byte Code
>> (http://sx.intel.com/p-553-intel-c-compiler-for-efi-byte-code.aspx)
>> is not open source, and also a pay software.
>> 
>> So i am wondering whether this kind of idea is valuable to the gcc
>> community?  or are there any other related ideas is more valuable?
> 
> There is no reason in principle this shouldn't be part of gcc.

I think the main issue is that EFI C dialect is not ANSI-C compliant: the size 
of pointer is determined
at the run-time and therefore the layout of the structure is not static.  Gcc 
doesn't support this model.

Tristan.

Re: (un)aligned accesses on x86 platform.

[Tristan Gingold]

On Mar 16, 2010, at 3:50 PM, H.J. Lu wrote:

> 2010/3/8 Paweł Sikora :
>> hi,
>> 
>> during development a cross platform appliacation on x86 workstation
>> i've enabled an alignemnt checking [1] to catch possible erroneous
>> code before it appears on client's sparc/arm cpu with sigbus ;)
>> 
>> it works pretty fine and catches alignment violations but Jakub Jelinek
>> had told me (on glibc bugzilla) that gcc on x86 can still dereference
>> an unaligned pointer (except for vector insns).
>> i suppose it means that gcc can emit e.g. movl for access a short int
>> (or maybe others scenarios) in some cases and violates cpu alignment rules.
>> 
>> so, is it possible to instruct gcc-x86 to always use suitable loads/stores
>> like on sparc/arm?
>> 
>> [1] "AC" bit - http://en.wikipedia.org/wiki/FLAGS_register_(computing)
>> 
> 
> I am interested in an -mstrict-alignment option for x86.

Not sure it will be useful.  The libc still does unaligned accesses IIRC.

Re: (un)aligned accesses on x86 platform.

[Tristan Gingold]

On Mar 16, 2010, at 4:37 PM, Alexey Salmin wrote:
>>> I am interested in an -mstrict-alignment option for x86.
>> 
>> Not sure it will be useful.  The libc still does unaligned accesses IIRC.
>> 
> 
> Wow. What for?

Well, simply because it is not compiled with strict alignment.  There might 
also be some optimization in
memory operation that does unaligned accesses.

Re: Idea for Google Summer Code : C Compiler for EFI Byte Code implement in gcc

[Tristan Gingold]

On Mar 19, 2010, at 1:33 PM, b95705...@ntu.edu.tw wrote:

> Hello Tristan,
> 
>> I think the main issue is that EFI C dialect is not ANSI-C compliant: the 
>> size of pointer is determined
>> at the run-time and therefore the layout of the structure is not static.  
>> Gcc doesn't support this model.
> 
> As I read some related information, LLVM IR doesn't care the size of pointer
> and the front end of LLVM is derived from GCC.I am wondering to know should
> I do some work at this aspect??

I don't know enough about LLVM to reply.  Sorry.  Try on the LLVM mailing list.

Re: Idea for Google Summer Code : C Compiler for EFI Byte Code implement in gcc

[Tristan Gingold]

On Mar 19, 2010, at 12:48 PM, b95705...@ntu.edu.tw wrote:
> I use Macbook with refit ,and its EFI shell version is 1.10.I have read
> some related information but I don't find how to launch EBC virture machine.
> I am truely want to know how could I launch it with fully appreciation.
> And I am wondering to know is there some EBC binery file to download that
> I can execute if I successfully launch EBC virture machine ??

Take a look at tianocore.org.  There is an open source implementation of EFI
(with a virtual machine), as well as some precompiled EBC files.

Tristan.

Re: gcc 4.5.0 vms-gcc_shell_handler.c needs #define __NEW_STARLET

[Tristan Gingold]

On May 3, 2010, at 12:02 PM, Jay K wrote:

> 
> /src/gcc-4.5.0/libgcc/../gcc/config/alpha/vms-gcc_shell_handler.c: In 
> function 'get_dyn_handler_pointer':
> /src/gcc-4.5.0/libgcc/../gcc/config/alpha/vms-gcc_shell_handler.c:73:3: 
> error: 'PDSCDEF' undeclared (first use in this function)
> /src/gcc-4.5.0/libgcc/../gcc/config/alpha/vms-gcc_shell_handler.c:73:3: note: 
> each undeclared identifier is reported only once for each function it appears 
> in
> /src/gcc-4.5.0/libgcc/../gcc/config/alpha/vms-gcc_shell_handler.c:73:13: 
> error: 'pd' undeclared (first use in this function)
> /src/gcc-4.5.0/libgcc/../gcc/config/alpha/vms-gcc_shell_handler.c:73:18: 
> warning: cast to pointer from integer of different size
> /src/gcc-4.5.0/libgcc/../gcc/config/alpha/vms-gcc_shell_handler.c:73:18: 
> error: expected expression before ')' token
> /src/gcc-4.5.0/libgcc/../gcc/config/alpha/vms-gcc_shell_handler.c:111:17: 
> warning: cast to pointer from integer of different size
> /src/gcc-4.5.0/libgcc/../gcc/config/alpha/vms-gcc_shell_handler.c:111:10: 
> warning: cast to pointer from integer of different size
> make[4]: *** [vms-gcc_shell_handler.o] Error 1
> make[3]: *** [multi-do] Error 1
> make[2]: *** [all-multi] Error 2
> make[1]: *** [all-target-libgcc] Error 2
> make: *** [all] Error 2
>  
>  
> fix, put this at top:
>   
>  
> #ifndef __NEW_STARLET
> #define __NEW_STARLET
> #endif

Hi,

yes, I think that the right thing to do.  You don't even need to protect the 
#define.
Could you submit formally a patch ?  Read the guidelines at 
http://gcc.gnu.org/contribute.html.

Thanks in advance,
Tristan.

Re: gcc 4.5.0 stddef.h clobbers __size_t with #define, breaks VMS (code already avoids similar on FreeBSD)

[Tristan Gingold]

On May 3, 2010, at 12:33 PM, Jay K wrote:

> 
> VMS decc$types.h:
> 
> typedef unsigned int __size_t;
> 
> but with GCC 4.5.0 this preprocesses as:
> 
> typedef unsigned int ;
> 
> and there are ensuing errors e.g. when compiling gcc/libiberty/regex.c
> 
> probably because of:
> 
> /usr/local/lib/gcc/alpha-dec-vms/4_5_0/include/stddef.h (it does get included)
> #if defined (__FreeBSD__) && (__FreeBSD__>= 5)
> /* __size_t is a typedef on FreeBSD 5!, must not trash it. */
> #else
> #define __size_t
> #endif
> 
> presumably should be more like:
> 
> #if (defined (__FreeBSD__) && (__FreeBSD__>= 5)) || defined(__vms)
> /* __size_t is a typedef on FreeBSD 5 and VMS, must not trash it! */
> #else
> #define __size_t
> #endif

Hi,

yes, I think this is necessary on VMS.  Could you submit formally a patch (I 
can't approve it, but it is
a required first step).

> That gets further, then hits 
> 
> 
> src/gcc-4.5.0/libiberty/regex.c: In function 'byte_insert_op2':
> /src/gcc-4.5.0/libiberty/regex.c:4279:1: error: unrecognizable insn:
> (insn 62 61 63 5 /src/gcc-4.5.0/libiberty/regex.c:4276 (set (reg:DI 135)
> (plus:SI (subreg/s:SI (reg/v/f:DI 109 [ pfrom ]) 0)
> (const_int 5 [0x5]))) -1 (nil))
> /src/gcc-4.5.0/libiberty/regex.c:4279:1: internal compiler error: in 
> extract_insn, at recog.c:2103
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See  for instructions.
> make: *** [regex.o] Error 1

I suppose you have hit a 32/64 pointer issue.  This requires some 
investigation!  We plan to fix them,
but we haven't yet started this work on gcc 4.5

Tristan.

Re: PATCH: 2 stage BFD linker for LTO plugin

[Tristan Gingold]

On Dec 6, 2010, at 6:23 PM, Dave Korn wrote:
>  Tristan, sorry, you must be sick of hearing from me by now,

No, not really :-)

> but I notice the
> branch was still labile a couple of hours ago... it would be really good if we
> could get HJ's patch approved and backported before you spin the release.

The issue is that this patch isn't yet approved for the trunk and looks 
slightly controversial.
And I'd like to make the release soon (ie this week).

Unless this patch is quickly approved (and back-ported), I plan to do the 
release this week.  If it is accepted after,
this is not a real issue as it can be part of binutils 2.21.1 (which should be 
released before March - or within gcc 4.6)

Tristan.

Re: [RFC / musing] Scoped exception handling in Linux userspace?

[Tristan Gingold]

On Jul 19, 2013, at 2:26 AM, Andy Lutomirski wrote:

> Windows has a feature that I've wanted on Linux forever: stack-based
> (i.e. scoped) exception handling.  The upshot is that you can do,
> roughly, this (pseudocode):

[...]

Indeed Windows and OpenVMS have such a mechanism. That's clean and
library friendly, but please read:
https://www.usenix.org/conference/wiess-2000/c-exception-handling-ia64
to understand how it hurts optimization.

(And no, raising an exception from an handler doesn't always work,
 due to optimizations allowed by the gcc exception mechanism).

Regards,
Tristan.

Re: [buildrobot] alpha64-dec-vms / alpha-dec-vms

[Tristan Gingold]

On 26 Nov 2013, at 04:23, Jan-Benedict Glaw  wrote:

> Hi!
> 
> Build log is available at
> http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=36942
> http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=40027

Yes, we are aware of that.  Basically, the openvms configuration doesn't yet 
support C++ :-(

There is scheduled work to support C++.

Tristan.

arm ttype encoding

[Tristan Gingold]

Hi,

we are currently working on the use of the arm ehabi for Ada exceptions,
and we aren't sure about which encoding has to be used for ttype.

The patch http://gcc.gnu.org/ml/gcc-patches/2011-09/msg00765.html
explains that on `Older ARM EABI toolchains set this value
[ttype_encoding] incorrectly`, and added the _GLIBCXX_OVERRIDE_TTYPE_ENCODING
workaround.

But that patch doesn't change it: in gcc/config/arm/arm.h,
ASM_PREFERRED_EH_DATA_FORMAT is defined only if ARM_TARGET2_DWARF_FORMAT isn't.

We are not sure wether this is the intent or an overlook.

The position of the #endif is important:

--- gcc/config/arm/arm.h(revision 178807)
+++ gcc/config/arm/arm.h(working copy)
@@ -825,6 +825,16 @@ extern int arm_arch_thumb_hwdiv;
 #define ARM_EH_STACKADJ_REGNUM 2
 #define EH_RETURN_STACKADJ_RTX gen_rtx_REG (SImode, ARM_EH_STACKADJ_REGNUM)
 
+#ifndef ARM_TARGET2_DWARF_FORMAT
+#define ARM_TARGET2_DWARF_FORMAT DW_EH_PE_pcrel
+
+/* ttype entries (the only interesting data references used)
+   use TARGET2 relocations.  */
+#define ASM_PREFERRED_EH_DATA_FORMAT(code, data) \
+  (((code) == 0 && (data) == 1 && ARM_UNWIND_INFO) ? ARM_TARGET2_DWARF_FORMAT \
+  : DW_EH_PE_absptr)
+#endif
+
 /* The native (Norcroft) Pascal compiler for the ARM passes the static chain
as an invisible last argument (possible since varargs don't exist in
Pascal), so the following is not true.  */

Can this be clarified ?

Thanks,
Tristan.

Re: Switching to C++ by default in 4.8

[Tristan Gingold]

On Apr 3, 2012, at 7:37 PM, Diego Novillo wrote:

> 
> We would like to start the process to make GCC 4.8 build in C++ mode by 
> default.
> 
> The mechanics of the change are simple enough.  I volunteer to test changing 
> the default on all primary targets (assuming I can get them from the GCC 
> build farm).

Is it already possible to build stage1 with c++ ?

The VMS targets are not yet ready with build in C++ mode.  This target is 
somewhat special because it can be built only with a cross-compiler (we don't 
support regular 3 stages native builds because there is no complete and working 
well enough UNIX emulation tools).

I started to build g++ (and gfortran) for ia64 and alpha VMS in order to 
prepare this transition, but having a soft path would be better to me.


(Clearly VMS is not a blocking target for the GCC community - that's not the 
point).

Tristan.

Re: Switching to C++ by default in 4.8

[Tristan Gingold]

On Apr 4, 2012, at 3:12 PM, Ian Lance Taylor wrote:

> Tristan Gingold  writes:
> 
>> On Apr 3, 2012, at 7:37 PM, Diego Novillo wrote:
>> 
>>> 
>>> We would like to start the process to make GCC 4.8 build in C++ mode by 
>>> default.
>>> 
>>> The mechanics of the change are simple enough.  I volunteer to test 
>>> changing the default on all primary targets (assuming I can get them from 
>>> the GCC build farm).
>> 
>> Is it already possible to build stage1 with c++ ?
> 
> Yes.  There are two relevant configure options: --enable-build-with-cxx

Ah thanks, I missed this option.

> and --enable-build-poststage1-with-cxx.  Currently the first defaults to
> no and the second defaults to yes.  The change in question would be
> making the first default to yes.
> 
> 
>> The VMS targets are not yet ready with build in C++ mode.  This target
>> is somewhat special because it can be built only with a cross-compiler
>> (we don't support regular 3 stages native builds because there is no
>> complete and working well enough UNIX emulation tools).
>> 
>> I started to build g++ (and gfortran) for ia64 and alpha VMS in order
>> to prepare this transition, but having a soft path would be better to
>> me.
> 
> Sounds like you would need to have a C++ cross-compiler for VMS.  What
> are the issues with making that work?

For ia64, g++ is working on simple examples (and for the testsuite).  But 
building gcc will be a better test.

For Alpha, gas crashes during libstdc++ build.  From initial investigation, 
this looks manageable.  But Alpha object format is quite old, and has no 
support for comdat (but weak symbols should work).  I only have worked on g++ 
for Alpha for a few days.

Tristan.

Re: Switching to C++ by default in 4.8

[Tristan Gingold]

On Apr 4, 2012, at 4:37 PM, Gabriel Dos Reis wrote:

> On Wed, Apr 4, 2012 at 8:32 AM, Tristan Gingold  wrote:
> 
>> For Alpha, gas crashes during libstdc++ build.  From initial investigation, 
>> this looks manageable.  But Alpha object format is quite old, and has no 
>> support for comdat (but weak symbols should work).
> 
> I believe weak symbols should suffice, if the object file does not have 
> comdat.

That's also my understanding from reading various gcc pieces.  But these 
features (aliases and weak) was never well-tested in the Alpha VMS case.

Tristan.

[Wiki] Building GCC in C++

[Tristan Gingold]

Hi,

I have added two entries:
alpha64-dec-openvms - currently as failed.  I still have to investigate the 
support of weak symbols by the assembler
ia64-hp-openvms - pass.  But it requires some patches for Ada.

Tristan.

Re: [Wiki] Building GCC in C++

[Tristan Gingold]

On Apr 10, 2012, at 3:07 PM, Diego Novillo wrote:

> On 4/10/12 8:41 AM, Tristan Gingold wrote:
>> Hi,
>> 
>> I have added two entries:
>> alpha64-dec-openvms - currently as failed.  I still have to investigate the 
>> support of weak symbols by the assembler
>> ia64-hp-openvms - pass.  But it requires some patches for Ada.
> 
> Thanks.  If the alpha64 failure is due to a bug, could you please file one 
> and add it as a dependency to 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44433?

I have created bug 52928.  However, as a VMS maintainer, I am not sure this is 
blocking.

Thanks,
Tristan.

Re: regression due to r187199 explow.c? in target ia64-hp-hpux11.23.

[Tristan Gingold]

Hi,

did you try with this patch:

http://gcc.gnu.org/ml/gcc-patches/2012-05/msg00970.html

Tristan.

On May 29, 2012, at 12:23 PM, Mailaripillai, Kannan Jeganathan wrote:

> Hi,
> 
> This modification (assertion) is causing failure in ia64-hp-hpux11.23:
> 
> r187199 | rsandifo | 2012-05-05 10:41:49 -0700 (Sat, 05 May 2012) | 247 lines
> Changed paths:
>   M /trunk/gcc/explow.c
>   * explow.c (plus_constant, plus_constant_mode): Likewise.  Assert that 
> the mode is sensible.
> 
> Haven't analyzed the issue. Thought of checking, if it is a known issue.
> 
> Error:
> --
> test.c: In function 'main':
> test.c:5:7: internal compiler error: in plus_constant, at explow.c:88
>   boo (&iarr[1]);
>   ^
> 
> Testcase (test.c):
> --
> int iarr[2];
> extern int boo(int *);
> 
> int main(void) {
>  boo (&iarr[1]);
>  return 0;
> }
> 
> Compilation command: 
> 
> gcc -c test.c
> ^ This compiler is built out of revision 187199 (trunk). Error attached above.
> 
> Configuration:
> --
> COLLECT_GCC=.../build-ia64-hp-hpux11.23-trunk/obj_gcc/gcc/xgcc
> Target: ia64-hp-hpux11.23
> Configured with: ...gcc/src/configure --host=ia64-hp-hpux11.23 
> --build=ia64-hp-hpux11.23 --prefix=.../gcc-ia64-hp-hpux11.23-trunk \
> --with-local-prefix=.../gcc-ia64-hp-hpux11.23-trunk --disable-nls \
> --with-gmp=.../ia64-hp-hpux11.23 --with-mpfr=.../ia64-hp-hpux11.23 \
> --with-mpc=.../ia64-hp-hpux11.23 --with-libelf=.../ia64-hp-hpux11.23 \
> --disable-libmudflap --enable-libunwind-exceptions SED=/usr/bin/sed \
> --enable-languages=c,c++,fortran
> Thread model: posix
> gcc version 4.8.0 20120505 (experimental) (GCC)
> COLLECT_GCC_OPTIONS='-B' '/.../build-ia64-hp-hpux11.23-trunk/obj_gcc/gcc/' 
> '-c' '-v'
> GNU C (GCC) version 4.8.0 20120505 (experimental) (ia64-hp-hpux11.23)
> compiled by GNU C version 4.5.1, GMP version 4.2.4, MPFR version 2.4.1, MPC 
> version 0.8
> GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
> 
> Regards,
> Kannan
> 

Re: regression due to r187199 explow.c? in target ia64-hp-hpux11.23.

[Tristan Gingold]

On Jun 6, 2012, at 9:10 AM, Mailaripillai, Kannan Jeganathan wrote:

> Hi Tristan,
> 
>>> http://gcc.gnu.org/ml/gcc-patches/2012-05/msg00970.html
>> I have not applied this patch. I will give it a try.
> 
> This patch is not fixing the issue. 
> Moreover, on compiling expr.c I get this warning:
>  /gcc/expr.c: In function 'expand_expr_addr_expr_1':
>  /gcc/expr.c:7603:10: warning: 'result' may be used uninitialized in 
>  this function.

That's looking weird.  I don't see how result can be used uninitialized as it 
is assigned just before.

Tristan.

> For the same testcase, now the ICE is happening in different place (while 
> compiling the same line of code):
>  test.c: In function 'main':
>  test.c:5:7: internal compiler error: Segmentation fault
> boo (&iarr[1]);
>   ^
> 
>  Stack trace got through gdb:
> 
> Program received signal SIGSEGV, Segmentation fault
>  si_code: 2 - SEGV_ACCERR - Invalid Permissions for object.
> 0x6c9dd60:1 in adjust_address_1 (memref=0x6544a140, mode=SImode, offset=-4,
>validate=1, adjust=1)
> (gdb) bt
> #0  0x6c9dd60:1 in adjust_address_1 (memref=0x6544a140, mode=SImode,
>offset=-4, validate=1, adjust=1)
> #1  0x957a110:0 in gen_lowpart_general (mode=SImode, x=0x6544a140)
> #2  0x6ee33e0:0 in convert_modes (mode=SImode, oldmode=DImode, x=0x6544a140,
>unsignedp=-1)
> #3  0x6dbc600:0 in convert_memory_address_addr_space (to_mode=SImode,
>x=0x6544a140, as=0 '\000')
> #4  0x6f39a60:0 in expand_expr_addr_expr_1 (exp=0x6544a140, target=0x0,
>tmode=SImode, modifier=EXPAND_NORMAL, as=0 '\000')
> #5  0x6f3ad50:0 in expand_expr_addr_expr (exp=0x65453678, target=0x0,
>tmode=SImode, modifier=EXPAND_NORMAL)
> #6  0x6f67f90:0 in expand_expr_real_1 (exp=0x65453678, target=0x0,
>tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0)
> #7  0x6f3c700:0 in expand_expr_real (exp=0x65453678, target=0x0,
>tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0)
> #8  0x5d4dda0:0 in expand_normal (exp=0x65453678)
> #9  0x5d8dce0:0 in precompute_register_parameters (num_actuals=1,
>args=0x7fffd8a0, reg_parm_seen=0x7fffdc88)
> #10 0x5da2160:0 in expand_call (exp=0x6544a258, target=0x0, ignore=1)
> #11 0x6f637c0:0 in expand_expr_real_1 (exp=0x6544a258, target=0x0,
>tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0)
> #12 0x5f6d760:0 in expand_call_stmt (stmt=0x6545c0b0)
> #13 0x5f6da90:0 in expand_gimple_stmt_1 (stmt=0x6545c0b0)
> 
> Testcase, GCC configuration, etc in the original post:
> http://gcc.gnu.org/ml/gcc/2012-05/msg00371.html
> 
> Regards,
> Kannan
> 
> -Original Message-
> From: Mailaripillai, Kannan Jeganathan 
> Sent: Wednesday, May 30, 2012 2:44 PM
> To: 'Tristan Gingold'
> Cc: gcc@gcc.gnu.org
> Subject: RE: regression due to r187199 explow.c? in target ia64-hp-hpux11.23.
> 
> Thanks Tristan. I have not applied this patch. I will give it a try.
> 
> Regards,
> Kannan
> 
> -Original Message-
> From: Tristan Gingold [mailto:ging...@adacore.com] 
> Sent: Wednesday, May 30, 2012 1:46 PM
> To: Mailaripillai, Kannan Jeganathan
> Cc: gcc@gcc.gnu.org
> Subject: Re: regression due to r187199 explow.c? in target ia64-hp-hpux11.23.
> 
> Hi,
> 
> did you try with this patch:
> 
> http://gcc.gnu.org/ml/gcc-patches/2012-05/msg00970.html
> 
> Tristan.
> 
> On May 29, 2012, at 12:23 PM, Mailaripillai, Kannan Jeganathan wrote:
> 
>> Hi,
>> 
>> This modification (assertion) is causing failure in ia64-hp-hpux11.23:
>> 
>> r187199 | rsandifo | 2012-05-05 10:41:49 -0700 (Sat, 05 May 2012) | 247 lines
>> Changed paths:
>>  M /trunk/gcc/explow.c
>>  * explow.c (plus_constant, plus_constant_mode): Likewise.  Assert that 
>>the mode is sensible.
>> 
>> Haven't analyzed the issue. Thought of checking, if it is a known issue.
>> 
>> Error:
>> --
>> test.c: In function 'main':
>> test.c:5:7: internal compiler error: in plus_constant, at explow.c:88
>>  boo (&iarr[1]);
>>  ^
>> 
>> Testcase (test.c):
>> --
>> int iarr[2];
>> extern int boo(int *);
>> 
>> int main(void) {
>> boo (&iarr[1]);
>> return 0;
>> }
>> 
>> Compilation command: 
>> 
>> gcc -c test.c
>> ^ This compiler is built out of revision 187199 (trunk). Error attached 
>> above.
>> 
>> Configuration:
>> --
>> COLLECT_GCC=.../build-ia64-hp-hpux11.23-trunk/obj_gcc/gcc/xgcc
>> Target: ia64-hp-hpux11.23
>> Configured with: ...gcc/src/con

Re: regression due to r187199 explow.c? in target ia64-hp-hpux11.23.

[Tristan Gingold]

On Jun 6, 2012, at 10:45 AM, Mailaripillai, Kannan Jeganathan wrote:

> Hi Tristan,
> 
>> how result can be used uninitialized as it is assigned just before
> 
> I am sorry. My mistake. I had replaced expand_expr_addr_expr_1 with 
> convert_memory_address_addr_space. I overlooked the patch as
> 
> -  result = expand_expr_addr_expr_1 (inner, subtarget, tmode, modifier, as);
> +  result = convert_memory_address_addr_space (tmode, result, as);
> 
> Hence replaced expand_expr_addr_expr_1 with convert_memory_address_addr_space.

That explains the crash too!

Tristan.

> 
> Regards,
> Kannan
> 
> -Original Message-
> From: Tristan Gingold [mailto:ging...@adacore.com] 
> Sent: Wednesday, June 06, 2012 1:17 PM
> To: Mailaripillai, Kannan Jeganathan
> Cc: gcc@gcc.gnu.org
> Subject: Re: regression due to r187199 explow.c? in target ia64-hp-hpux11.23.
> 
> 
> On Jun 6, 2012, at 9:10 AM, Mailaripillai, Kannan Jeganathan wrote:
> 
>> Hi Tristan,
>> 
>>>> http://gcc.gnu.org/ml/gcc-patches/2012-05/msg00970.html
>>> I have not applied this patch. I will give it a try.
>> 
>> This patch is not fixing the issue. 
>> Moreover, on compiling expr.c I get this warning:
>> /gcc/expr.c: In function 'expand_expr_addr_expr_1':
>> /gcc/expr.c:7603:10: warning: 'result' may be used uninitialized in 
>> this function.
> 
> That's looking weird.  I don't see how result can be used uninitialized as it 
> is assigned just before.
> 
> Tristan.
> 
>> For the same testcase, now the ICE is happening in different place (while 
>> compiling the same line of code):
>> test.c: In function 'main':
>> test.c:5:7: internal compiler error: Segmentation fault
>>boo (&iarr[1]);
>>  ^
>> 
>>  Stack trace got through gdb:
>> 
>> Program received signal SIGSEGV, Segmentation fault
>> si_code: 2 - SEGV_ACCERR - Invalid Permissions for object.
>> 0x6c9dd60:1 in adjust_address_1 (memref=0x6544a140, mode=SImode, offset=-4,
>>   validate=1, adjust=1)
>> (gdb) bt
>> #0  0x6c9dd60:1 in adjust_address_1 (memref=0x6544a140, mode=SImode,
>>   offset=-4, validate=1, adjust=1)
>> #1  0x957a110:0 in gen_lowpart_general (mode=SImode, x=0x6544a140)
>> #2  0x6ee33e0:0 in convert_modes (mode=SImode, oldmode=DImode, x=0x6544a140,
>>   unsignedp=-1)
>> #3  0x6dbc600:0 in convert_memory_address_addr_space (to_mode=SImode,
>>   x=0x6544a140, as=0 '\000')
>> #4  0x6f39a60:0 in expand_expr_addr_expr_1 (exp=0x6544a140, target=0x0,
>>   tmode=SImode, modifier=EXPAND_NORMAL, as=0 '\000')
>> #5  0x6f3ad50:0 in expand_expr_addr_expr (exp=0x65453678, target=0x0,
>>   tmode=SImode, modifier=EXPAND_NORMAL)
>> #6  0x6f67f90:0 in expand_expr_real_1 (exp=0x65453678, target=0x0,
>>   tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0)
>> #7  0x6f3c700:0 in expand_expr_real (exp=0x65453678, target=0x0,
>>   tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0)
>> #8  0x5d4dda0:0 in expand_normal (exp=0x65453678)
>> #9  0x5d8dce0:0 in precompute_register_parameters (num_actuals=1,
>>   args=0x7fffd8a0, reg_parm_seen=0x7fffdc88)
>> #10 0x5da2160:0 in expand_call (exp=0x6544a258, target=0x0, ignore=1)
>> #11 0x6f637c0:0 in expand_expr_real_1 (exp=0x6544a258, target=0x0,
>>   tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0)
>> #12 0x5f6d760:0 in expand_call_stmt (stmt=0x6545c0b0)
>> #13 0x5f6da90:0 in expand_gimple_stmt_1 (stmt=0x6545c0b0)
>> 
>> Testcase, GCC configuration, etc in the original post:
>> http://gcc.gnu.org/ml/gcc/2012-05/msg00371.html
>> 
>> Regards,
>> Kannan
>> 
>> -Original Message-
>> From: Mailaripillai, Kannan Jeganathan 
>> Sent: Wednesday, May 30, 2012 2:44 PM
>> To: 'Tristan Gingold'
>> Cc: gcc@gcc.gnu.org
>> Subject: RE: regression due to r187199 explow.c? in target ia64-hp-hpux11.23.
>> 
>> Thanks Tristan. I have not applied this patch. I will give it a try.
>> 
>> Regards,
>> Kannan
>> 
>> -Original Message-
>> From: Tristan Gingold [mailto:ging...@adacore.com] 
>> Sent: Wednesday, May 30, 2012 1:46 PM
>> To: Mailaripillai, Kannan Jeganathan
>> Cc: gcc@gcc.gnu.org
>> Subject: Re: regression due to r187199 explow.c? in target ia64-hp-hpux11.23.
>> 
>> Hi,
>> 
>> did you try with this patch:
>> 
>> http://gcc.gnu.org/ml/gcc-patches/2012-05/msg00970.html
>> 
>> Tristan.
>> 
>> On May 29, 2012, at 12:23 PM, Mailaripillai, Kannan Jeganathan wrote:
>> 
>

Re: regression due to r187199 explow.c? in target ia64-hp-hpux11.23.

[Tristan Gingold]

On Jun 6, 2012, at 12:27 PM, Mailaripillai, Kannan Jeganathan wrote:

> Hi Tristan,
> 
> After applying the patch (correctly) the build proceeded further. 
> Now the build hits on another error, while compiling /libgomp/parallel.c:
> 
> /libgomp/parallel.c: In function 'omp_get_ancestor_thread_num':
> /libgomp/parallel.c:166:1: internal compiler error: in plus_constant, at 
> explow.c:88
> omp_get_ancestor_thread_num (int level)
> ^
> 
> Is there another patch to solve this issue?
> Basically, my bootstrap build (ia64-hpux-11.23) is failing due to this.

I haven't tried to build for ia64-hpux, only for ia64-openvms (which doesn't 
support omp).
What is the backtrace ?

Tristan.

> 
> Regards,
> Kannan
> 
> -Original Message-
> From: Mailaripillai, Kannan Jeganathan 
> Sent: Wednesday, June 06, 2012 2:15 PM
> To: 'Tristan Gingold'
> Cc: gcc@gcc.gnu.org
> Subject: RE: regression due to r187199 explow.c? in target ia64-hp-hpux11.23.
> 
> Hi Tristan,
> 
>> how result can be used uninitialized as it is assigned just before
> 
> I am sorry. My mistake. I had replaced expand_expr_addr_expr_1 with 
> convert_memory_address_addr_space. I overlooked the patch as
> 
> -  result = expand_expr_addr_expr_1 (inner, subtarget, tmode, modifier, as);
> +  result = convert_memory_address_addr_space (tmode, result, as);
> 
> Hence replaced expand_expr_addr_expr_1 with convert_memory_address_addr_space.
> 
> Regards,
> Kannan
> 
> -Original Message-
> From: Tristan Gingold [mailto:ging...@adacore.com] 
> Sent: Wednesday, June 06, 2012 1:17 PM
> To: Mailaripillai, Kannan Jeganathan
> Cc: gcc@gcc.gnu.org
> Subject: Re: regression due to r187199 explow.c? in target ia64-hp-hpux11.23.
> 
> 
> On Jun 6, 2012, at 9:10 AM, Mailaripillai, Kannan Jeganathan wrote:
> 
>> Hi Tristan,
>> 
>>>> http://gcc.gnu.org/ml/gcc-patches/2012-05/msg00970.html
>>> I have not applied this patch. I will give it a try.
>> 
>> This patch is not fixing the issue. 
>> Moreover, on compiling expr.c I get this warning:
>> /gcc/expr.c: In function 'expand_expr_addr_expr_1':
>> /gcc/expr.c:7603:10: warning: 'result' may be used uninitialized in 
>> this function.
> 
> That's looking weird.  I don't see how result can be used uninitialized as it 
> is assigned just before.
> 
> Tristan.
> 
>> For the same testcase, now the ICE is happening in different place (while 
>> compiling the same line of code):
>> test.c: In function 'main':
>> test.c:5:7: internal compiler error: Segmentation fault
>>boo (&iarr[1]);
>>  ^
>> 
>>  Stack trace got through gdb:
>> 
>> Program received signal SIGSEGV, Segmentation fault
>> si_code: 2 - SEGV_ACCERR - Invalid Permissions for object.
>> 0x6c9dd60:1 in adjust_address_1 (memref=0x6544a140, mode=SImode, offset=-4,
>>   validate=1, adjust=1)
>> (gdb) bt
>> #0  0x6c9dd60:1 in adjust_address_1 (memref=0x6544a140, mode=SImode,
>>   offset=-4, validate=1, adjust=1)
>> #1  0x957a110:0 in gen_lowpart_general (mode=SImode, x=0x6544a140)
>> #2  0x6ee33e0:0 in convert_modes (mode=SImode, oldmode=DImode, x=0x6544a140,
>>   unsignedp=-1)
>> #3  0x6dbc600:0 in convert_memory_address_addr_space (to_mode=SImode,
>>   x=0x6544a140, as=0 '\000')
>> #4  0x6f39a60:0 in expand_expr_addr_expr_1 (exp=0x6544a140, target=0x0,
>>   tmode=SImode, modifier=EXPAND_NORMAL, as=0 '\000')
>> #5  0x6f3ad50:0 in expand_expr_addr_expr (exp=0x65453678, target=0x0,
>>   tmode=SImode, modifier=EXPAND_NORMAL)
>> #6  0x6f67f90:0 in expand_expr_real_1 (exp=0x65453678, target=0x0,
>>   tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0)
>> #7  0x6f3c700:0 in expand_expr_real (exp=0x65453678, target=0x0,
>>   tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0)
>> #8  0x5d4dda0:0 in expand_normal (exp=0x65453678)
>> #9  0x5d8dce0:0 in precompute_register_parameters (num_actuals=1,
>>   args=0x7fffd8a0, reg_parm_seen=0x7fffdc88)
>> #10 0x5da2160:0 in expand_call (exp=0x6544a258, target=0x0, ignore=1)
>> #11 0x6f637c0:0 in expand_expr_real_1 (exp=0x6544a258, target=0x0,
>>   tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0)
>> #12 0x5f6d760:0 in expand_call_stmt (stmt=0x6545c0b0)
>> #13 0x5f6da90:0 in expand_gimple_stmt_1 (stmt=0x6545c0b0)
>> 
>> Testcase, GCC configuration, etc in the original post:
>> http://gcc.gnu.org/ml/gcc/2012-05/msg00371.html
>> 
>> Regards,
>> Kannan
>> 
>> -Original Message-
>> From: Ma

Re: regression due to r187199 explow.c? in target ia64-hp-hpux11.23.

[Tristan Gingold]

Hi,

so it looks like there are other ia64 specific calls to plus_constant that need 
to be adjusted.

Tristan.

On Jun 6, 2012, at 1:29 PM, Mailaripillai, Kannan Jeganathan wrote:

>>>> What is the backtrace ?
>> #0  0x6db96a0:0 in plus_constant (mode=RFmode, x=0x18, c=1)
>> #13 0x6f68260:0 in expand_expr_real_1 (exp=0x651ab420, target=0x0,
> 
> Full backtrace:
> 
> #0  0x6db96a0:0 in plus_constant (mode=RFmode, x=0x18, c=1)
> #1  0xd7503f0:0 in ia64_expand_tls_address (tls_kind=TLS_MODEL_INITIAL_EXEC,
>op0=0x651ac120, op1=0x651ac0f0, orig_op1=0x651ac0f0, addend=0)
> #2  0xd750dd0:0 in ia64_expand_move (op0=0x651ac120, op1=0x651ac0f0)
> #3  0xd8c6e90:0 in gen_movsi (operand0=0x651ac120, operand1=0x651ac0f0)
> #4  0x6ef9900:0 in emit_move_insn_1 (x=0x651ac120, y=0x651ac0f0)
> #5  0x6efa6f0:0 in emit_move_insn (x=0x651ac120, y=0x651ac0f0)
> #6  0x6dbdd30:0 in copy_to_mode_reg (mode=SImode, x=0x651ac0f0)
> #7  0x8ba3c30:0 in maybe_legitimize_operand (icode=CODE_FOR_addsi3, opno=1,
>op=0x7fffcf88)
> #8  0x8ba46c0:0 in maybe_legitimize_operands (icode=CODE_FOR_addsi3, opno=0,
>nops=3, ops=0x7fffcf80)
> #9  0x8ba48c0:0 in maybe_gen_insn (icode=CODE_FOR_addsi3, nops=3,
>ops=0x7fffcf80)
> #10 0x8b6b620:0 in expand_binop_directly (mode=SImode, binoptab=0x40257fdc,
>op0=0x651ac0f0, op1=0x653ba4f0, target=0x0, unsignedp=1,
>methods=OPTAB_LIB_WIDEN, last=0x0)
> #11 0x8b6bcb0:0 in expand_binop (mode=SImode, binoptab=0x40257fdc,
>op0=0x651ac0f0, op1=0x653ba4f0, target=0x0, unsignedp=1,
>methods=OPTAB_LIB_WIDEN)
> #12 0x6f4fa30:0 in expand_expr_real_2 (ops=0x7fffdcd4, target=0x0,
>tmode=SImode, modifier=EXPAND_NORMAL)
> #13 0x6f68260:0 in expand_expr_real_1 (exp=0x651ab420, target=0x0,
>tmode=SImode, modifier=EXPAND_NORMAL, alt_rtl=0x0)
> #14 0x6f3c830:0 in expand_expr_real (exp=0x651ab420, target=0x0, tmode=SImode,
>modifier=EXPAND_NORMAL, alt_rtl=0x0)
> #15 0x6e7c5e0:0 in expand_expr (exp=0x651ab420, target=0x0, mode=SImode,
>modifier=EXPAND_NORMAL)
> #16 0x6f37cc0:0 in expand_expr_addr_expr_1 (exp=0x651a2900, target=0x0,
>tmode=SImode, modifier=EXPAND_NORMAL, as=0 '\000')
> #17 0x6f3adb0:0 in expand_expr_addr_expr (exp=0x651a8558, target=0x0,
>tmode=SImode, modifier=EXPAND_NORMAL)
> #18 0x6f67ff0:0 in expand_expr_real_1 (exp=0x651a8558, target=0x0,
>tmode=SImode, modifier=EXPAND_NORMAL, alt_rtl=0x0)
> #19 0x6f3c830:0 in expand_expr_real (exp=0x651a8558, target=0x0, tmode=SImode,
>modifier=EXPAND_NORMAL, alt_rtl=0x0)
> #20 0xaa49f90:0 in expand_expr (exp=0x651a8558, target=0x0, mode=SImode,
>modifier=EXPAND_NORMAL)
> #21 0xaa4ee60:0 in insert_value_copy_on_edge (e=0x655a4e40, dest=8,
>src=0x651a8558, locus=1363692)
> #22 0xaa53730:0 in eliminate_phi (e=0x655a4e40, g=0x404d6de0)
> #23 0xaa54d70:0 in expand_phi_nodes (sa=0x4012623c)
> #24 0x5f909d0:0 in gimple_expand_cfg ()
> #25 0x8d130d0:0 in execute_one_pass (pass=0x400451b8)
> #26 0x8d137f0:0 in execute_pass_list (pass=0x400451b8)
> #27 0x656d740:0 in expand_function (node=0x65550450)
> #28 0x656eb60:0 in expand_all_functions ()
> #29 0x6571400:0 in compile ()
> #30 0x6571940:0 in finalize_compilation_unit ()
> #31 0x51bc8e0:0 in c_write_global_declarations ()
> #32 0x9c63b30:0 in compile_file ()
> #33 0x9c6b470:0 in do_compile ()
> #34 0x9c6b9c0:0 in toplev_main (argc=49, argv=0x7fffeee8)
> #35 0xf564740:0 in main (argc=49, argv=0x7fffeee8)
> 
> Regards,
> Kannan
> 
> -Original Message-
> From: Mailaripillai, Kannan Jeganathan 
> Sent: Wednesday, June 06, 2012 4:42 PM
> To: 'Tristan Gingold'
> Cc: gcc@gcc.gnu.org
> Subject: RE: regression due to r187199 explow.c? in target ia64-hp-hpux11.23.
> 
> 
>> What is the backtrace ?
> 
> #0  0x6db96a0:0 in plus_constant (mode=RFmode, x=0x18, c=1)
> #1  0xd7503f0:0 in ia64_expand_tls_address (tls_kind=TLS_MODEL_INITIAL_EXEC,
>op0=0x651ac120, op1=0x651ac0f0, orig_op1=0x651ac0f0, addend=0)
> #2  0xd750dd0:0 in ia64_expand_move (op0=0x651ac120, op1=0x651ac0f0)
> #3  0xd8c6e90:0 in gen_movsi (operand0=0x651ac120, operand1=0x651ac0f0)
> #4  0x6ef9900:0 in emit_move_insn_1 (x=0x651ac120, y=0x651ac0f0)
> #5  0x6efa6f0:0 in emit_move_insn (x=0x651ac120, y=0x651ac0f0)
> #6  0x6dbdd30:0 in copy_to_mode_reg (mode=SImode, x=0x651ac0f0)
> #7  0x8ba3c30:0 in maybe_legitimize_operand (icode=CODE_FOR_addsi3, opno=1,
>op=0x7fffcf88)
> #8  0x8ba46c0:0 in maybe_legitimize_operands (icode=CODE_FOR_addsi3, opno=0,
>nops=3, ops=0x7fffcf80)
> #9  0x8ba48c0:0 in maybe_gen_insn (icode=CODE_FOR_addsi3, nops=3,
>ops=0x7fffcf80)
> #10 0x8b6b620:0 in expand_binop_directly (mode=SImode, binoptab=0x40257fdc,
>op0=0x651ac0f0, op1=0x653ba4f0, targ

Re: libbacktrace and darwin

[Tristan Gingold]

On Oct 4, 2012, at 11:23 PM, Ian Lance Taylor wrote:

> On Thu, Oct 4, 2012 at 1:32 PM, Jack Howarth  wrote:
>>   Is libbacktrace currently functional in gcc trunk and is it expected
>> to function on darwin? While I could understand it not working on installed
>> binaries of FSF gcc that were stripped, I would think it should work for
>> make check in the build tree since all of the debug code should be present
>> in the object files. Or doesn't libbacktrace know to look there for the
>> dwarf code? Thanks in advance for any clarifications.
> 
> libbacktrace is functional in GCC trunk.  However, it does not yet
> support the Mach-O object file format.  I hope to work on that at some
> point, but it would be great if somebody else tackled it.  It's
> probably straightforward to implement based on code in
> libiberty/simple-object-mach-o.c.

I doubt it will, as dwarf info aren't in the executable.  I think it will be
simpler to support .dsym (separate debug file) at first.

Tristan.

Re: libbacktrace and darwin

[Tristan Gingold]

On Oct 5, 2012, at 11:37 AM, Richard Guenther wrote:

> On Fri, Oct 5, 2012 at 9:15 AM, Tristan Gingold  wrote:
>> 
>> On Oct 4, 2012, at 11:23 PM, Ian Lance Taylor wrote:
>> 
>>> On Thu, Oct 4, 2012 at 1:32 PM, Jack Howarth  
>>> wrote:
>>>>  Is libbacktrace currently functional in gcc trunk and is it expected
>>>> to function on darwin? While I could understand it not working on installed
>>>> binaries of FSF gcc that were stripped, I would think it should work for
>>>> make check in the build tree since all of the debug code should be present
>>>> in the object files. Or doesn't libbacktrace know to look there for the
>>>> dwarf code? Thanks in advance for any clarifications.
>>> 
>>> libbacktrace is functional in GCC trunk.  However, it does not yet
>>> support the Mach-O object file format.  I hope to work on that at some
>>> point, but it would be great if somebody else tackled it.  It's
>>> probably straightforward to implement based on code in
>>> libiberty/simple-object-mach-o.c.
>> 
>> I doubt it will, as dwarf info aren't in the executable.  I think it will be
>> simpler to support .dsym (separate debug file) at first.
> 
> So I take it that libbacktrace doesn't work with the separate DWARF
> debuginfo as shipped by all Linux distributions either?

I don't know, but the Mach-O mechanism to get the separate debug file is 
different from ELF.

Re: Implementing VMX128 AltiVec Variant

[Tristan Gingold]

On Aug 21, 2007, at 11:49 PM, Gordan Bobic wrote:


These are the only place I found references to them, apart from the  
files in the gcc/ada directory:


gcc/ada/g-alveop.adb
gcc/ada/g-alveop.ads
gcc/ada/g-alleve.adb
gcc/ada/g-alleve.ads

I ignored these - I am making a rash assumption here that these are  
not too important for a C/C++ only build, but I'd like some  
confirmation on that. What are the above ada files for?


These are the Ada bindings to the altivec instructions.  You can of  
course ignore this if you are not

interested in Ada.

Tristan.