Please don't cross-post to several mailing lists, this belongs on the
gcc-help mailing list only.
On Wed, 1 Mar 2023, 06:33 Kondreddy, Vinay Kumar, <
vinaykumar.kondre...@staples.com> wrote:
> Hi Team,
>
>
>
> We are using GCC 4.8.3 for one of our legacy applications i.e: Automatch.
> after dat
On Thu, Oct 06, 2022 at 06:57:40PM -0400, Michael Collison wrote:
> I am trying to improve code generation for coremark to match a recent
> improvement that was made in LLVM.
>
> I added the following transformation to match.pd which attempts to replace a
> branch with straight line code:
>
> /*
On Thu, Oct 6, 2022 at 4:00 PM Michael Collison wrote:
>
> I am trying to improve code generation for coremark to match a recent
> improvement that was made in LLVM.
>
> I added the following transformation to match.pd which attempts to
> replace a branch with straight line code:
>
> /* (cond (and
On Apr 20, 2021, at 9:11 AM, Gabriel Paubert
mailto:paub...@iram.es>> wrote:
(lldb) di -s 0x000103d6 -c 10
libgambit.dylib`___SCMOBJ_to_NONNULLSTRING:
0x103d6 <+1504>: jl 0x103d60026 ; <+1542> at
c_intf.c:3282:9
0x103d60002 <+1506>: orb%al, 0x31(%rbp)
0
On Tue, Apr 20, 2021 at 12:20:06PM +, Lucier, Bradley J via Gcc wrote:
> I’m seeing an “Illegal Instruction” fault and don’t quite know how to
> generate a proper bug report yet.
>
> This is the compiler:
>
> [Bradleys-Mac-mini:~] lucier% /usr/local/gcc-10.3.0/bin/gcc -v
> Using built-in spe
Lucier, Bradley J via Gcc wrote:
I’m seeing an “Illegal Instruction” fault and don’t quite know how to
generate a proper bug report yet.
This is the compiler:
[Bradleys-Mac-mini:~] lucier% /usr/local/gcc-10.3.0/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/usr/local/gcc-10.3.0/bin/gcc
COLLE
On Fri, Jul 29, 2016 at 11:05:13AM +0200, Georg-Johann Lay wrote:
> There might still problems linger around if hard-regs are used:
>
> Suppose we set the reg in DImode and then get_last_value is called for the
> same reg in SImode. Using the DI value might be wrong, e.g. if it is used
> to com
On 29.07.2016 09:47, Segher Boessenkool wrote:
Hi Johann,
I tested a variant of your patch, building Linux for 32 different
(sub-)architectures; surprisingly (to me) there are no regressions
at all.
I am not so surprised because most backends don't make such an intense use of
hard-regs like t
Hi Johann,
I tested a variant of your patch, building Linux for 32 different
(sub-)architectures; surprisingly (to me) there are no regressions
at all.
Do you want to send it to gcc-patches?
Segher
diff --git a/gcc/combine.c b/gcc/combine.c
index 77e0d2b..750bf83 100644
--- a/gcc/combine.c
++
On Wed, Jul 27, 2016 at 09:14:27PM +0200, Georg-Johann Lay wrote:
> >diff --git a/gcc/combine.c b/gcc/combine.c
> >index 77e0d2b..dec6226 100644
> >--- a/gcc/combine.c
> >+++ b/gcc/combine.c
> >@@ -9977,6 +9977,9 @@ reg_num_sign_bit_copies_for_combine (const_rtx x,
> >machine_mode mode,
> >
Segher Boessenkool schrieb:
On Tue, Jul 26, 2016 at 03:38:18PM +0200, Georg-Johann Lay wrote:
@@ -13206,6 +13206,13 @@ get_last_value (const_rtx x)
&& DF_INSN_LUID (rsp->last_set) >= subst_low_luid)
return 0;
+ /* If the lookup is for a hard register make sure that value contains
at
On Tue, Jul 26, 2016 at 03:38:18PM +0200, Georg-Johann Lay wrote:
> >>@@ -13206,6 +13206,13 @@ get_last_value (const_rtx x)
> >> && DF_INSN_LUID (rsp->last_set) >= subst_low_luid)
> >> return 0;
> >>
> >>+ /* If the lookup is for a hard register make sure that value contains
> >>at
> >>
On 26.07.2016 14:51, Segher Boessenkool wrote:
On Tue, Jul 26, 2016 at 02:14:49PM +0200, Georg-Johann Lay wrote:
which returns const0_rtx because reg 18 is set in insn 43 to const0_rtx.
Total outcome is that the right shift of reg:DI 18 is transformed to a
no-op move and cancelled out in the rem
On Tue, Jul 26, 2016 at 02:14:49PM +0200, Georg-Johann Lay wrote:
> >>which returns const0_rtx because reg 18 is set in insn 43 to const0_rtx.
> >>Total outcome is that the right shift of reg:DI 18 is transformed to a
> >>no-op move and cancelled out in the remainder.
> >
> >Why does num_sign_bit_c
On 25.07.2016 23:05, Segher Boessenkool wrote:
On Mon, Jul 25, 2016 at 02:28:28PM +0200, Georg-Johann Lay wrote:
(insn 43 31 44 2 (set (reg:QI 18 r18)
(const_int 0 [0])) bug-combin.c:29 56 {movqi_insn}
(nil))
(insn 51 50 52 2 (set (reg:QI 16 r16)
(const_int 40 [0x28])) bu
On Mon, Jul 25, 2016 at 02:28:28PM +0200, Georg-Johann Lay wrote:
> (insn 43 31 44 2 (set (reg:QI 18 r18)
> (const_int 0 [0])) bug-combin.c:29 56 {movqi_insn}
> (nil))
> (insn 51 50 52 2 (set (reg:QI 16 r16)
> (const_int 40 [0x28])) bug-combin.c:29 56 {movqi_insn}
> (nil)
On 11/04/15 04:08, Kumar Aditya wrote:
> I am new user of Linux. I have RHEL 6.0 installed and want to run C++
> on my system but I do not know how.
yum install gcc-c++.
Andrew.
Hey Kumar.
Just use your package manager.
in terminal:
yum search gcc-c++
Determine which version are available.
Then run:
yum install gcc-c++
You will need root access for the install step.
If you want another version RPM’s can be found here:
http://www.rpmfind.net/linux/rpm2h
On Wed, 25 Feb 2015, Sandra Loosemore wrote:
>> Patch is a part of a series which is waiting for additional steering
>> committee approval due to copyright and a license.
> I don't imagine the documentation for *features already committed*
> needs to wait for steering committee approval; per the G
On 02/25/2015 09:47 AM, Ilya Enkovich wrote:
2015-02-25 19:16 GMT+03:00 Sandra Loosemore :
On 02/25/2015 12:56 AM, Ilya Enkovich wrote:
2015-02-24 19:47 GMT+03:00 Sandra Loosemore :
Poking around, I see that the -fcheck-pointer-bounds and various -fchkp-*
options are listed in c-family/c.op
2015-02-25 19:16 GMT+03:00 Sandra Loosemore :
> On 02/25/2015 12:56 AM, Ilya Enkovich wrote:
>>
>> 2015-02-24 19:47 GMT+03:00 Sandra Loosemore :
>>>
>>>
>>> Poking around, I see that the -fcheck-pointer-bounds and various -fchkp-*
>>> options are listed in c-family/c.opt, but they are not listed in
On 02/25/2015 12:56 AM, Ilya Enkovich wrote:
2015-02-24 19:47 GMT+03:00 Sandra Loosemore :
Poking around, I see that the -fcheck-pointer-bounds and various -fchkp-*
options are listed in c-family/c.opt, but they are not listed in the GCC
manual. The section on intrinsics is not enough, by itse
2015-02-24 19:47 GMT+03:00 Sandra Loosemore :
> On 02/24/2015 01:14 AM, Ilya Enkovich wrote:
>>
>> 2015-02-20 19:39 GMT+03:00 Sandra Loosemore :
>>>
>>> On 02/20/2015 01:12 AM, Ilya Enkovich wrote:
2015-02-20 3:48 GMT+03:00 Sandra Loosemore :
>
>
> The section "Pointer Bo
On 02/24/2015 01:14 AM, Ilya Enkovich wrote:
2015-02-20 19:39 GMT+03:00 Sandra Loosemore :
On 02/20/2015 01:12 AM, Ilya Enkovich wrote:
2015-02-20 3:48 GMT+03:00 Sandra Loosemore :
The section "Pointer Bounds Checker builtins" in extend.texi is on my
list
for being in need of copy-editing, b
2015-02-20 19:39 GMT+03:00 Sandra Loosemore :
> On 02/20/2015 01:12 AM, Ilya Enkovich wrote:
>>
>> 2015-02-20 3:48 GMT+03:00 Sandra Loosemore :
>>>
>>> The section "Pointer Bounds Checker builtins" in extend.texi is on my
>>> list
>>> for being in need of copy-editing, but reading through the exist
On 02/20/2015 01:12 AM, Ilya Enkovich wrote:
2015-02-20 3:48 GMT+03:00 Sandra Loosemore :
The section "Pointer Bounds Checker builtins" in extend.texi is on my list
for being in need of copy-editing, but reading through the existing text, I
am quite confused. In several places it refers to turn
2015-02-20 3:48 GMT+03:00 Sandra Loosemore :
> The section "Pointer Bounds Checker builtins" in extend.texi is on my list
> for being in need of copy-editing, but reading through the existing text, I
> am quite confused. In several places it refers to turning the Pointer
> Bounds Checker off, but
On Mon, Feb 17, 2014 at 5:28 AM, Richard Biener
wrote:
> On Mon, Feb 17, 2014 at 1:15 PM, Dominik Vogt wrote:
>> On Fri, Feb 14, 2014 at 02:40:44PM +0100, Richard Biener wrote:
>>> On Fri, Feb 14, 2014 at 9:59 AM, Dominik Vogt
>>> wrote:
>>> > Given a specific VAR_DECL tree node, I need to find
On Mon, Feb 17, 2014 at 1:15 PM, Dominik Vogt wrote:
> On Fri, Feb 14, 2014 at 02:40:44PM +0100, Richard Biener wrote:
>> On Fri, Feb 14, 2014 at 9:59 AM, Dominik Vogt
>> wrote:
>> > Given a specific VAR_DECL tree node, I need to find out whether
>> > its type is built in or not. Up to now I ha
On Fri, Feb 14, 2014 at 02:40:44PM +0100, Richard Biener wrote:
> On Fri, Feb 14, 2014 at 9:59 AM, Dominik Vogt wrote:
> > Given a specific VAR_DECL tree node, I need to find out whether
> > its type is built in or not. Up to now I have
> >
> > tree tn = TYPE_NAME (TREE_TYPE (var_decl));
> >
On Fri, Feb 14, 2014 at 9:59 AM, Dominik Vogt wrote:
> Given a specific VAR_DECL tree node, I need to find out whether
> its type is built in or not. Up to now I have
>
> tree tn = TYPE_NAME (TREE_TYPE (var_decl));
> if (tn != NULL_TREE && TREE_CODE (tn) == TYPE_DECL && DECL_NAME (tn))
>
On Mon, Oct 31, 2011 at 10:58:03AM -0500, Moffett, Kyle D wrote:
> I have not yet been able to figure out if it's a libgcc issue or an
> actual compiler issue.
It is a gcc bug. I've added a comment to the PR.
--
Alan Modra
Australia Development Lab, IBM
On 08/23/2010 11:05 AM, Mohamed Shafi wrote:
> sub.s32 srcdstGP, #imm16 // signed 16-bit register to immediate subtract
> sub.u32 srcdstGP, #imm16 // unsigned 16-bit register to immediate subtract
Having both of these is probably not useful. Bernd pointed
out that a 17-bit constant would be more
On 08/23/2010 08:05 PM, Mohamed Shafi wrote:
> sub.s32 srcdstGP, #imm16 // signed 16-bit register to immediate subtract
> sub.u32 srcdstGP, #imm16 // unsigned 16-bit register to immediate subtract
If you're using a bit to decide between these two, a better encoding
would be to just support a sing
Mohamed Shafi writes:
> I want to know if it is good to have both sign and zero extension for
> 16bit immediate.
Hard to say. It really depends on the kind of constants you expect your
programs to use. It's generally a good idea to have an efficient way to
load small constants which many progr
Thanks
I am submitting patch to drop count to 10,000 for 16 bit int target.
Using 32 bit counter of 1 million takes a minute or so on simulator -
which is high.
The lower count is quick and only requires a (16bit) stack limit to be
lower than 10MB - which is pretty safe.
Andy
Joseph S. My
On Sun, 6 Dec 2009, Andrew Hutchinson wrote:
> The test appears to be unsafe. The original fault was failure to deallocate
> VLA on the jump - thus with the fault present the test would appear to perform
> 1 million new allocation - and fail presumably due to either execution time or
> run time er
Shankar Iyer writes:
> I have compiled and generated a C++ shared library with the "-fPIC" option.
> But this shared library requires text relocation during runtime and is not
> usable on seLinux which disables writeable text segments. The text relocation
> is due to use of exceptions inside
Vikram KS wrote:
So in the back-end there are driver options that will help me to
invoke the existing tool-chain through GCC driver. But the assembler
takes only .sl extensions. I tried to replace the .s extension with
.sl extension. But by default the cc1 will have some options passed
from the
On Thu, Jul 30, 2009 at 8:14 PM, Basile STARYNKEVITCH
wrote:
>
> Vikram KS wrote:
>>
>> Hi,
>>
>> I have some question on gcc driver.
>
> You really should give more context. Are you doing cross-compilation? Are you
> patching the GCC sources? Why do you want to generate a *.sl file? What are
>
Vikram KS wrote:
Hi,
I have some question on gcc driver.
You really should give more context. Are you doing cross-compilation?
Are you patching the GCC sources? Why do you want to generate a *.sl
file? What are your host & target systems?
Whenever we invoke gcc, it'll pass some default opt
This list is for discussing GCC development, not deal with usage
problems. Please try asking [EMAIL PROTECTED]
Thanks,
Ben
On Mon, Feb 25, 2008 at 3:23 PM, Mag cool <[EMAIL PROTECTED]> wrote:
> hi, i am a beginner in this tech world. i want to learn 1/how to do
> programming in c in unix or linux. i don't know anything about linux. where
> to start.
>
Try this book: http://www.advancedlinuxprogramming.com/
>
>
>
Michael_fogel writes:
> Hello
>
> For my diploma thesis I have to implement a new back-end for GCC.
> The microcontroller is based on an FPGA and was developed one year ago.
> Only an Assembler is available and now my university lecturer wants an C
> compiler too. I decided to use GCC in v
> I don't know about using reference types, but there are several math
> builtins that "return" multiple values, the extra ones via pointer
> arguments. E.g. see frexp, lgamma_r, modf, remquo and/or sincos.
Like I said, I'm kinda locked into the syntax. People have been using
these builtins for
On Thu, 9 Aug 2007, DJ Delorie wrote:
> Could someone provide a hint for me? I'm trying to put in "real"
> prototypes for a builtin function where the arguments don't follow the
> default promotion rules. Specifically, one of the arguments is a
> reference type (like C++'s "int&"). However, I'm
I'm hoping I can get it to do what I want, if only I can get the MI to
treat the function definition given to it by the target as the one
true definition, and not just some advisory one.
DJ Delorie <[EMAIL PROTECTED]> writes:
> Is there a trick to this? I need this type of functionality because
> some builtins modify multiple values, so a simple return value is
> insufficient, plus this worked with older versions of gcc so our users
> are used to it syntax-wise.
I've never found
[EMAIL PROTECTED] writes:
> I am getting the following compilation error:
>
> /tmp/ccIUvX3i.o(.gnu.linkonce.d._ZTV4ListIiE+0x8): undefined reference to
> `List::Find(int const&)'
Wrong mailing list. This sort of question should go to
[EMAIL PROTECTED] Thanks.
I don't know the answer to your q
On Jun 28, 2006, at 1:59 PM, [EMAIL PROTECTED] wrote:
I am a PhD student working on optimal instruction scheduling
problems. I want to
integrate my scheduler into the GCC. Can you tell me where to
start? and
important links which can be helpful for the integration work?
I'd start by downlo
On May 16, 2006, at 7:39 PM, fsshl plinlin wrote:
Dear gcc and/or apple OS X 7.9 users:
Union-Souths-Computer:~/gcc-5250 UnionSouth$ cat config.log
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.
configure:595: chec
Hi Dan,
Reply below.
Best regards
On Thu, 4 Aug 2005 02:05, Dan Kegel wrote:
> "Paul C. Leopardi" <[EMAIL PROTECTED]> wrote:
> > So I seem to be left with a large ( >2.5MB ) preprocessed source file.
> > Should I try to report the bug using this large file as a test case?
>
> Sure. But you might
Hi Volker,
On Thu, 4 Aug 2005 02:31 am, Volker Reichelt wrote:
> You might want to try a recent snapshot of gcc 4.0.2, first.
> Two aliasing bugs got fixed after the 4.0.1 release:
>
> http://gcc.gnu.org/PR22591
> http://gcc.gnu.org/PR23192
>
> The first even caused std::list::swap to be miscompile
Paul Leopardi wrote:
> I have now downloaded, bootstapped and installed gcc 4.0.1. The bug in g++
> optimization is still there. I've made an attempt to follow the instructions
> on minimizing test cases and have so far accomplished:
> wc of old preprocessed source:
> 99412 260586 2965538 peg
2nd implementation?:
http://www.cs.berkeley.edu/~dsw/
This is what we all use, AFAIK :)
"Paul C. Leopardi" <[EMAIL PROTECTED]> wrote:
> So I seem to be left with a large ( >2.5MB ) preprocessed source file. Should
> I try to report the bug using this large file as a test case?
Sure. But you might want to try using an automated tool
to reduce the test case first. There's one called
Hi Janis,
A belated reply to your message is below.
Best regards, Paul Leopardi
On Tue, 17 May 2005 03:23 am, Janis Johnson wrote:
> On Sat, May 14, 2005 at 12:16:54PM +1000, Paul C. Leopardi wrote:
> > Hi all,
> > I originally posted these messages to gcc-help, but had no reply, so I am
> > re-po
On Sat, May 14, 2005 at 12:16:54PM +1000, Paul C. Leopardi wrote:
> Hi all,
> I originally posted these messages to gcc-help, but had no reply, so I am
> re-posting links to them here.
>
> I think I have found a bug in g++ 4.0.0, but need help in reporting it.
> Maintainers like their bug repor
Andrew,
Thanks for reminding me about this. I'll need to take a good look at this.
The effect of the workaround is to change any instance of _GLUCAT_PRIVATE to
public. This does not affect the validity or otherwise of the g++ bug I'm
currently trying to report.
I wrote GluCat at a time when ea
On May 13, 2005, at 10:16 PM, Paul C. Leopardi wrote:
+//* workaround for ICC, G++ 3.3+, G++ 4.0+
Why do you need this work around? Why has this not been filed or really
fixed in their sources?
-- Pinski
60 matches
Mail list logo
