On 3/8/24 5:30 AM, Jonathan Wakely via Gcc wrote:
> Patches should be sent to the gcc-patches list instead of this one,
> and should be against trunk not an old gcc-11 RC. See
> https://gcc.gnu.org/contribute.html#patches for more details - thanks!
And you need to CC the rs6000/powerpc port mainta
, since reworking the rs6000 .machine output selection in
> commit e154242724b084380e3221df7c08fcdbd8460674 22 May 2019, G5 as
> well as Cell, and even power4 w/ -maltivec currently resulted in
> power7. Mask _ALTIVEC away as the .machine selection already did for
> GFX and GPOPT.
>
e154242724b084380e3221df7c08fcdbd8460674 22 May 2019, G5 as
well as Cell, and even power4 w/ -maltivec currently resulted in
power7. Mask _ALTIVEC away as the .machine selection already did for
GFX and GPOPT.
powerpc64-t2-linux-gnu-gcc test.c -S -o - -mcpu=G5
.file "test.c"
.mach
gi?id=110926 .
Thanks,
Andrew
> > > >
> > > > To quote:
> > > >
> > > > during RTL pass: split1
> > > > /home/toon/compilers/gcc/libgfortran/generated/matmul_i1.c: In function
> > > > 'matmul_i1_avx512f&
> 'matmul_i1_avx512f':
> > > /home/toon/compilers/gcc/libgfortran/generated/matmul_i1.c:1781:1:
> > > internal compiler error: RTL check: expected elt 0 type 'i' or 'n', have
> > > 'w' (rtx const_int) in vpternlog_redundant_operand_m
ers/gcc/libgfortran/generated/matmul_i1.c:1781:1:
> > internal compiler error: RTL check: expected elt 0 type 'i' or 'n', have
> > 'w' (rtx const_int) in vpternlog_redundant_operand_mask, at
> > config/i386/i386.cc:19460
> > 1781 | }
>
ed/matmul_i1.c: In function
> 'matmul_i1_avx512f':
> /home/toon/compilers/gcc/libgfortran/generated/matmul_i1.c:1781:1:
> internal compiler error: RTL check: expected elt 0 type 'i' or 'n', have
> 'w' (rtx const_int) in vpternlog_redundant_operand_mask, at
/generated/matmul_i1.c:1781:1:
internal compiler error: RTL check: expected elt 0 type 'i' or 'n', have
'w' (rtx const_int) in vpternlog_redundant_operand_mask, at
config/i386/i386.cc:19460
1781 | }
| ^
during RTL pass: split1
/home/toon/compilers/gcc/libgfo
Hello!
My name is Manish, I live in India. I have over 14+ years of working
experience in designing and developing user-friendly websites.
I'll be glad to assist you with:
WordPress websites,
Elementor,
Shopify,
Javascript,
PHP, (Laravel)
SQL,
JQuery,
HTML5,
CSS3,
E-commerce,
Magento,
t; find_first_bit(), find_first_and_bit(), find_first_and_bit() and
> > > find_first_and_bit() all invokes GENMASK(size - 1, 0).
> > >
> > > This triggers below warning when compiled with W=2.
> > >
> > > | ./include/linux/find.h: In function &#x
t; >
> > > On Wed, Apr 27, 2022 at 01:16:58AM +0900, Vincent Mailhol wrote:
> > > > find_first_bit(), find_first_and_bit(), find_first_and_bit() and
> > > > find_first_and_bit() all invokes GENMASK(size - 1, 0).
> > > >
> > > > This triggers be
ilhol wrote:
> > > find_first_bit(), find_first_and_bit(), find_first_and_bit() and
> > > find_first_and_bit() all invokes GENMASK(size - 1, 0).
> > >
> > > This triggers below warning when compiled with W=2.
> > >
> > > | ./include/linux/find.h: In function
From: Vincent MAILHOL
Date: Wed, 27 Apr 2022 11:58:58 +0900
> + Alexander Lobakin
I was okay even with the previous solution to modify
GENMASK_INPUT_CHECK() and this one is fine to me as well.
The presense of warnings on W=1 doesn't mean we shouldn't fix W=12
etc. Especially when
it() all invokes GENMASK(size - 1, 0).
> >
> > This triggers below warning when compiled with W=2.
> >
> > | ./include/linux/find.h: In function 'find_first_bit':
> > | ./include/linux/bits.h:25:36: warning: comparison of unsigned
>
+ gcc@gcc.gnu.org
+ Rikard Falkeborn
On Wed, Apr 27, 2022 at 01:16:58AM +0900, Vincent Mailhol wrote:
> find_first_bit(), find_first_and_bit(), find_first_and_bit() and
> find_first_and_bit() all invokes GENMASK(size - 1, 0).
>
> This triggers below warning when compi
办QO
理 $ +Q+V+信/-
--
& $ -- I 3 4
髮 $--- 2 4 3 4
& $ ---6 1 4 8
漂 $
-2019/3/10
r suggestions for tweaks I'll commit
>>> this updated comment this week.
>>
>> Please do not commit such changes w/o approval.
>
> Since you're the second maintainer to ask me that in response
> to a patch to update comments I'd like to get some clarity he
On 11/28/18 6:35 AM, Richard Biener wrote:
On Tue, Nov 27, 2018 at 3:52 AM Martin Sebor wrote:
Ping: https://gcc.gnu.org/ml/gcc-patches/2018-11/msg01759.html
If there are no objections or suggestions for tweaks I'll commit
this updated comment this week.
Please do not commit such chan
On 8/14/17, Alan Modra wrote:
> On Sun, Aug 13, 2017 at 10:25:14PM +0930, Alan Modra wrote:
>> On Sun, Aug 13, 2017 at 03:35:15AM -0700, David Wohlferd wrote:
>> > Using "m"(*pStr) as an (unused) input parameter has no effect.
>>
>> Use "m" (*(const void *)pStr) and ignore the warning, or use
>> "
On Thu, Aug 17, 2017 at 04:27:12PM +0200, Michael Matz wrote:
> Hi,
>
> On Mon, 14 Aug 2017, Alan Modra wrote:
>
> > I've opened https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81845 to track
> > the lack of documentation.
>
> You mean like in this paragraph discussing memory clobbers and uses in
Hi,
On Mon, 14 Aug 2017, Alan Modra wrote:
> I've opened https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81845 to track
> the lack of documentation.
You mean like in this paragraph discussing memory clobbers and uses in
extended asms that we have since 2004? :
If your assembler
On Tue, Aug 15, 2017 at 03:09:15PM +0800, Liu Hao wrote:
> On 2017/8/14 20:41, Alan Modra wrote:
> >On Sun, Aug 13, 2017 at 10:25:14PM +0930, Alan Modra wrote:
> >>On Sun, Aug 13, 2017 at 03:35:15AM -0700, David Wohlferd wrote:
> >>>Using "m"(*pStr) as an (unused) input parameter has no effect.
> >
On 2017/8/14 20:41, Alan Modra wrote:
On Sun, Aug 13, 2017 at 10:25:14PM +0930, Alan Modra wrote:
On Sun, Aug 13, 2017 at 03:35:15AM -0700, David Wohlferd wrote:
Using "m"(*pStr) as an (unused) input parameter has no effect.
Use "m" (*(const void *)pStr) and ignore the warning, or use
"m" (*(
On Sun, Aug 13, 2017 at 10:25:14PM +0930, Alan Modra wrote:
> On Sun, Aug 13, 2017 at 03:35:15AM -0700, David Wohlferd wrote:
> > Using "m"(*pStr) as an (unused) input parameter has no effect.
>
> Use "m" (*(const void *)pStr) and ignore the warning, or use
> "m" (*(const struct {char a; char x[];
On Sun, Aug 13, 2017 at 03:35:15AM -0700, David Wohlferd wrote:
> Using "m"(*pStr) as an (unused) input parameter has no effect.
Use "m" (*(const void *)pStr) and ignore the warning, or use
"m" (*(const struct {char a; char x[];} *) pStr).
The issue is one of letting gcc know what memory is acces
On 8/12/2017 10:14 PM, Andrew Pinski wrote:
On Sat, Aug 12, 2017 at 10:08 PM, Andrew Pinski wrote:
On Sat, Aug 12, 2017 at 9:21 PM, David Wohlferd wrote:
Environment:
gcc 6.1
compiling for 64bit i386
optimizations: -O2
Consider this simple bit of code (from
https://stackoverflow.com/a/456560
On Sat, Aug 12, 2017 at 9:21 PM, David Wohlferd wrote:
> Environment:
> gcc 6.1
> compiling for 64bit i386
> optimizations: -O2
>
> Consider this simple bit of code (from
> https://stackoverflow.com/a/45656087/2189500):
>
> #include
>
> int getStringLength(const char *pStr){
>
> int len;
>
>
On Sat, Aug 12, 2017 at 10:08 PM, Andrew Pinski wrote:
> On Sat, Aug 12, 2017 at 9:21 PM, David Wohlferd
> wrote:
>> Environment:
>> gcc 6.1
>> compiling for 64bit i386
>> optimizations: -O2
>>
>> Consider this simple bit of code (from
>> https://stackoverflow.com/a/45656087/2189500):
>>
>> #inc
Environment:
gcc 6.1
compiling for 64bit i386
optimizations: -O2
Consider this simple bit of code (from
https://stackoverflow.com/a/45656087/2189500):
#include
int getStringLength(const char *pStr){
int len;
__asm__ (
"repne scasb\n\t"
"not %%ecx\n\t"
"dec
On Thu, Aug 07, 2014 at 10:01:30AM -0600, Jeff Law wrote:
> On 08/07/14 03:16, Jonathan Wakely wrote:
> >On 7 August 2014 06:33, Joshua Kinardwrote:
> >>For my own information, what's the cutoff date for fixes to regressions like
> >>this to make it into gcc-4.9.1?
> >
> >A month ago, https://gcc.g
On 08/07/14 03:16, Jonathan Wakely wrote:
On 7 August 2014 06:33, Joshua Kinardwrote:
For my own information, what's the cutoff date for fixes to regressions like
this to make it into gcc-4.9.1?
A month ago, https://gcc.gnu.org/ml/gcc/2014-07/msg00103.html
The GCC home page has links to the st
On 7 August 2014 06:33, Joshua Kinardwrote:
> For my own information, what's the cutoff date for fixes to regressions like
> this to make it into gcc-4.9.1?
A month ago, https://gcc.gnu.org/ml/gcc/2014-07/msg00103.html
The GCC home page has links to the status report emails for each active branch.
On 07/28/2014 17:38, Matthew Fortune wrote:
> I'll switch to replying on PR61538. I had not read all the ticket
> previously and although I may have found a problem it seems it may not
> be the cause of this failure.
>
> The generated code differences after the patches seem significant but
> I may
etail for a little
while.
Matthew
> -Original Message-
> From: Joshua Kinard [mailto:ku...@gentoo.org]
> Sent: 28 July 2014 10:40
> To: Matthew Fortune; gcc@gcc.gnu.org
> Subject: Re: Help w/ PR61538?
>
> On 07/28/2014 04:41, Matthew Fortune wrote:
> > Hi Joshua,
inated via Ctrl+C.
>> I
>>> suspect it's a double-locking bug of some design, as evidenced by strace
>>> showing two consecutive syscall()'s w/ 0x108e passed as the syscall #
>> (4238
>>> or futex on o32 MIPS), but I am stumped as to what else I can do to
ctly on SGI R1x000-based systems
> > (Octane, Onyx2), running Linux. Running the subsequently-compiled
> > application simply hangs in a futex syscall until terminated via Ctrl+C.
> I
> > suspect it's a double-locking bug of some design, as evidenced by strace
>
simply hangs in a futex syscall until terminated via Ctrl+C. I
> suspect it's a double-locking bug of some design, as evidenced by strace
> showing two consecutive syscall()'s w/ 0x108e passed as the syscall # (4238
> or futex on o32 MIPS), but I am stumped as to what else I
it's a double-locking bug of some design, as evidenced by strace
showing two consecutive syscall()'s w/ 0x108e passed as the syscall # (4238
or futex on o32 MIPS), but I am stumped as to what else I can do to debug it
and help fix it.
I haven't fully determined if the flaw originate
org, "Will Deacon"
> , lttng-...@lists.lttng.org, "Andrew Morton"
> , "Paul E. McKenney"
> , "Linus Torvalds"
> Sent: Tuesday, November 19, 2013 5:25:18 PM
> Subject: Re: [lttng-dev] Multiple local register variables w/ same register
>
> --
n Lynch" , "Paul E.
> McKenney"
> , "Linus Torvalds"
> , "Andrew Morton"
> , "Jakub Jelinek" ,
> gcc@gcc.gnu.org
> Sent: Tuesday, November 19, 2013 4:56:57 PM
> Subject: Multiple local register variables w/ same register
>
> On 11
Richard Henderson writes:
> On 11/20/2013 03:33 AM, Peter Zijlstra wrote:
>> On Tue, Nov 19, 2013 at 05:02:20PM +, Mathieu Desnoyers wrote:
>>> Unfortunately I don't have a ARM cross-compiler setup ready. Nathan
>>> could test it for us though.
>>>
>>> It might shuffle things around enough to
On Wed, Nov 20, 2013 at 07:56:57AM +1000, Richard Henderson wrote:
> It appears not:
>
> int __attribute__((noinline)) f(void)
> {
> {
> register int x __asm__("eax");
> x = 1;
> }
> {
> register int y __asm__("eax");
> return ++y;
> }
> }
>
> extern void abort(void);
>
>
On 11/20/2013 03:33 AM, Peter Zijlstra wrote:
> On Tue, Nov 19, 2013 at 05:02:20PM +, Mathieu Desnoyers wrote:
>> Unfortunately I don't have a ARM cross-compiler setup ready. Nathan could
>> test
>> it for us though.
>>
>> It might shuffle things around enough to work around the issue, but wit
On Fri, May 17, 2013 at 5:36 PM, Ryan Johnson
wrote:
> On 17/05/2013 6:18 PM, Ian Lance Taylor wrote:
>>
>> On Fri, May 17, 2013 at 1:04 PM, Ryan Johnson
>> wrote:
>>>
>>> Is there a reason user C/C++ apps shouldn't be able to incorporate
>>> libbacktrace, or is it just an oversight/TODO? It work
On 17/05/2013 6:18 PM, Ian Lance Taylor wrote:
On Fri, May 17, 2013 at 1:04 PM, Ryan Johnson
wrote:
Is there a reason user C/C++ apps shouldn't be able to incorporate
libbacktrace, or is it just an oversight/TODO? It works beautifully if I
copy the relevant files to where they belong in the ins
On Fri, May 17, 2013 at 1:04 PM, Ryan Johnson
wrote:
>
> Is there a reason user C/C++ apps shouldn't be able to incorporate
> libbacktrace, or is it just an oversight/TODO? It works beautifully if I
> copy the relevant files to where they belong in the install tree [2]; it
> also seems to work jus
Hi all,
(Please CC me in replies, not a list member)
I'd like to use libbacktrace in a C++ app built by gcc-4.8.0 [1], but it
seems that the target library doesn't actually get installed, even
though it's built.
Is there a reason user C/C++ apps shouldn't be able to incorporate
libbacktrace
On 23.09.12 18:24, Richard Guenther wrote:
On Sat, Sep 22, 2012 at 9:40 AM, Andreast Tobler
wrote:
Hi all,
while testing some patches fro Michael M, I noticed that disable-checking
seems broken on trunk. I saw this on x86_64-freebsd and powerpc64-freebsd.
Is this issue already known?
If not,
On Sat, Sep 22, 2012 at 9:40 AM, Andreast Tobler
wrote:
> Hi all,
>
> while testing some patches fro Michael M, I noticed that disable-checking
> seems broken on trunk. I saw this on x86_64-freebsd and powerpc64-freebsd.
>
> Is this issue already known?
> If not, usual bug report with preprocessed
Hi all,
while testing some patches fro Michael M, I noticed that
disable-checking seems broken on trunk. I saw this on x86_64-freebsd and
powerpc64-freebsd.
Is this issue already known?
If not, usual bug report with preprocessed source?
TIA;
Andreas
Here the details:
-
/export/devel/ne
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
- prowadzonej prze Kancelarię
Podatkową z 19 - letnim doświadczeniem na rynku i wysokokwalifikowaną kadrą
księgowych,
- Obniżeniem kosztów przy zachowaniu najwyższych standardów obsługi - dzięki
oprogramowaniu najnowszej generacji możliwa obsługa nawet dużych firm w
systemie on-line z calego kraju
On 02/01/2011 04:54 AM, Dave Korn wrote:
On 01/02/2011 02:33, Joel Sherrill wrote:
Should LTO work with a target not using gold?
Yes, it should, but some work is needed at the binutils end. I am testing
the attached two patches at the moment; the idea is to have fully-debugged
support for
On Tue, Feb 1, 2011 at 10:39 AM, Dave Korn wrote:
> On 01/02/2011 18:01, H.J. Lu wrote:
>
FWIW, your recan linker patch doesn't fix LTO 8, which is:
http://sourceware.org/bugzilla/show_bug.cgi?id=12277
>>> It wasn't supposed to, we've been through this before. It needs both the
>>
On 01/02/2011 18:01, H.J. Lu wrote:
>>> FWIW, your recan linker patch doesn't fix LTO 8, which is:
>>>
>>> http://sourceware.org/bugzilla/show_bug.cgi?id=12277
>> It wasn't supposed to, we've been through this before. It needs both the
>> link-order fix *and* the rescan-libs fix. The combined p
On Tue, Feb 1, 2011 at 9:52 AM, Dave Korn wrote:
> On 01/02/2011 17:15, H.J. Lu wrote:
>> On Tue, Feb 1, 2011 at 2:54 AM, Dave Korn wrote:
>>> On 01/02/2011 02:33, Joel Sherrill wrote:
Hi,
There are ~100 failures on each *-rtems* target
in the latest test runs when various lto
On 01/02/2011 17:15, H.J. Lu wrote:
> On Tue, Feb 1, 2011 at 2:54 AM, Dave Korn wrote:
>> On 01/02/2011 02:33, Joel Sherrill wrote:
>>> Hi,
>>>
>>> There are ~100 failures on each *-rtems* target
>>> in the latest test runs when various lto related
>>> flags are on. The symbols in questions are i
On Tue, Feb 1, 2011 at 2:54 AM, Dave Korn wrote:
> On 01/02/2011 02:33, Joel Sherrill wrote:
>> Hi,
>>
>> There are ~100 failures on each *-rtems* target
>> in the latest test runs when various lto related
>> flags are on. The symbols in questions are in the
>> RTEMS libraries which are picked up
On 01/02/2011 14:30, Joel Sherrill wrote:
> On 02/01/2011 04:54 AM, Dave Korn wrote:
>> On 01/02/2011 02:33, Joel Sherrill wrote:
>>> Should LTO work with a target not using gold?
>>Yes, it should, but some work is needed at the binutils end. I am
>> testing
>> the attached two patches at the
On 02/01/2011 04:54 AM, Dave Korn wrote:
On 01/02/2011 02:33, Joel Sherrill wrote:
Hi,
There are ~100 failures on each *-rtems* target
in the latest test runs when various lto related
flags are on. The symbols in questions are in the
RTEMS libraries which are picked up via the
-B... argument.
On Tue, Feb 1, 2011 at 11:54 AM, Dave Korn wrote:
> On 01/02/2011 02:33, Joel Sherrill wrote:
>> Hi,
>>
>> There are ~100 failures on each *-rtems* target
>> in the latest test runs when various lto related
>> flags are on. The symbols in questions are in the
>> RTEMS libraries which are picked u
On 01/02/2011 02:33, Joel Sherrill wrote:
> Hi,
>
> There are ~100 failures on each *-rtems* target
> in the latest test runs when various lto related
> flags are on. The symbols in questions are in the
> RTEMS libraries which are picked up via the
> -B... argument. Other symbols from the same
>
/builtins/fprintf-lib.c
/users/joel/test-gcc/gcc-svn/gcc/testsuite/gcc.c-torture/execute/builtins/lib/main.c
gcc_tg.o -w -O2 -flto -flto-partition=none -DSTACK_SIZE=2048
-isystem
/users/joel/test-gcc/b-gcc1-m32r/m32r-rtems4.11/./newlib/targ-include
-isystem /users/joel/test-gcc/gcc-svn/newlib
This bogus size of -1 is causing an informational warning from VMS Debug
on IA64 VMS. It would be useful to us if approved and merged.
--Douglas Rupp
AdaCore
Äú ºÃ £¡
±¾¹«Ë¾ÏÖÓи÷ÐÐÒµ¹ú/µØË°
ÔöÖµ¡£ÆÕͨ¡£½¨Öþ£¬¹ã¸æ¡£·þÎñ¡£¹¤³Ì¡£ÔËÊäµÈа淢 Øâ ´ú¿ª ¿ÉÓúø¶¿î ´¹Ñ¯µç»°
13528406753 ÁõÉú
When registers are saved in the prologue, there can be stalls if there
are lingering latencies because the values haven't been computed or loaded
yet. Likewise, when the epilogue restores registers, there will be stalls
if the last one (or one of the last few, depending on latency) is
accessed imm
te arguments (1, should be 2)
> t.cpp:2: error: provided for 'template class B'
> t.cpp:12: error: default argument missing for parameter 2 of 'D::D(int,
> A)'
>
> If I write D(int n_ = (B::i) ), then it compiles. Imho it should
> compile w/o the extra parenthe
n it compiles. Imho it should
compile w/o the extra parentheses. VC++ 2008 Express compiled it. Wanted
to test gcc 4.4, too, but I wasn't able to compile the 20081003 snapshot
(/usr/include/gnu/stubs.h:7:27: error: gnu/stubs-32.h: No such file or
directory). I have a debian lenny/amd64 system.
Regards, P
OK for the latter, why not?
There was certainly a time when it would not, because a R/M/W cycle on
a device register meant a different thing that a read followed by a write
and the latter is more clearly what the above is supposed to represent.
Whether there is still such hardware around is anothe
t;
> I think it would still be OK for the latter, why not?
There was certainly a time when it would not, because a R/M/W cycle on
a device register meant a different thing that a read followed by a write
and the latter is more clearly what the above is supposed to represent.
Whether there is
Richard Kenner wrote:
Right, but it would seem this is a good canididate for combination. This
is especially true since often Volatile is used with the sense of Atomic
in Ada, and it is not a bad idea to combine these in practice, giving an
atomic update (right, nothing in the language requires i
> Right, but it would seem this is a good canididate for combination. This
> is especially true since often Volatile is used with the sense of Atomic
> in Ada, and it is not a bad idea to combine these in practice, giving an
> atomic update (right, nothing in the language requires it, but it is
> d
Richard Kenner wrote:
OK, sounds reasonable, but then I don't understand the logic behind
avoiding this instruction sequence for the volatile case, this is
two accesses at the bus level so what's the difference?
There's no difference from that perspective. The logic behind what's
generated is
> OK, sounds reasonable, but then I don't understand the logic behind
> avoiding this instruction sequence for the volatile case, this is
> two accesses at the bus level so what's the difference?
There's no difference from that perspective. The logic behind what's
generated is that instead of tr
Samuel Tardieu wrote:
For this pattern (isolated setting of one bit in the middle of a byte at
a random memory location), this is the best code on this platform AFAIK.
As an evidence, if you mark neither variable as volatile GCC generates
with -O3 -fomit-frame-pointer:
f:
orb $16,
On 1/12, Robert Dewar wrote:
>> I cannot see a reason not to use "orb $32,y" here instead of a three
>> steps read/modify/write operation. Is this only a missed optimization?
>> (in which case I will open a PR)
>
> Are you sure it is an optimization, the timing on these things is
> very subtle. W
Samuel Tardieu wrote:
When looking at an Ada PR, I stumbled upon the equivalent of the
following C code:
unsigned char x;
volatile unsigned char y;
void f ()
{
x |= 16;
y |= 32;
}
With trunk/i686, the following code is generated (-O3 -fomit-frame-pointer):
f:
movzbl y
> volatile unsigned char y;
> void f ()
> {
> y |= 32;
> }
>
> I cannot see a reason not to use "orb $32,y" here instead of a three
> steps read/modify/write operation. Is this only a missed optimization?
No, it's purposeful. The idea was that this is completely equivalent to
y =
When looking at an Ada PR, I stumbled upon the equivalent of the
following C code:
unsigned char x;
volatile unsigned char y;
void f ()
{
x |= 16;
y |= 32;
}
With trunk/i686, the following code is generated (-O3 -fomit-frame-pointer):
f:
movzbl y, %eax
orb $
We set has_volatile_ops on all(?) memory references during early
optimization because we don't have alias information. But we
do it inconsistently for loads. For example I see
D.2574_23 = *D.2573_22;
(no volatile) and
D.2565_28 ={v} tab[D.2560_27].__delta;
(volatile). Because for indire
Serdecznie zapraszamy na
MiÄdzynarodowÄ
Polsko - UkraiÅskÄ
konferencjÄ na temat
"Polska - Ukraina: sami budujemy przyszÅoÅÄ"
XXI MiÄdzynarodowa konferencja
> ROZWÃJ INWESTYCJI W UKRAINIE
- teraż
Serdecznie zapraszamy na
Międzynarodową Polsko - Ukraińską konferencję na temat
"Polska - Ukraina: sami budujemy przyszłość"
XX Międzynarodowa konferencja
> INWESTYCYJNE INTERESY W UKRAINIE
Aktualne informacje.Ostateczne
On Thu, Nov 17, 2005 at 08:17:07AM +0100, Peter S. Mazinger wrote:
> -fstack-protector-all (all protection) being superset of -fstack-protector
> (random protection) it should also define __SSP__ 1
The IBM patch that I followed did exactly what I implemented.
I see no compelling reason to change
On Thu, 17 Nov 2005, Peter S. Mazinger wrote:
> On Wed, 16 Nov 2005, Richard Henderson wrote:
>
> > On Wed, Nov 16, 2005 at 10:32:45PM +0100, Peter S. Mazinger wrote:
> > > what happens w/ -fstack-protector-all -fstack-protector (in this order) ?
> > > do we have
On Wed, 16 Nov 2005, Richard Henderson wrote:
> On Wed, Nov 16, 2005 at 10:32:45PM +0100, Peter S. Mazinger wrote:
> > what happens w/ -fstack-protector-all -fstack-protector (in this order) ?
> > do we have (2) or (1)
>
> We have 1.
>
> > so now it does
> >
On Wed, Nov 16, 2005 at 10:32:45PM +0100, Peter S. Mazinger wrote:
> what happens w/ -fstack-protector-all -fstack-protector (in this order) ?
> do we have (2) or (1)
We have 1.
> so now it does
> -fstack-protector #define __SSP__ 1 ; #undef __SSP_ALL__
> -fstack-protec
; > > > defaults to no-ssp), so -fno-stack-protector-all should be there too
> > > > >
> > > > > Why? What option would it perform?
> > > >
> > > > to have the possibility to override an earlier one, as it is done w/
> > > >
Why? What option would it perform?
> > >
> > > to have the possibility to override an earlier one, as it is done w/ many
> > > fno* options. Why should this one not have it's counterpart.
> >
> > There are three states we can be in:
> >
>
xactly this, gcc supports -fno-stack-protector (although gcc
> > > > defaults to no-ssp), so -fno-stack-protector-all should be there too
> > >
> > > Why? What option would it perform?
> >
> > to have the possibility to override an earlier one, as it is
; > defaults to no-ssp), so -fno-stack-protector-all should be there too
> >
> > Why? What option would it perform?
>
> to have the possibility to override an earlier one, as it is done w/ many
> fno* options. Why should this one not have it's counterpart.
There a
What option would it perform?
to have the possibility to override an earlier one, as it is done w/ many
fno* options. Why should this one not have it's counterpart.
Ex. gcc does not default to fomit-frame-pointer, but we have
fno-omit-frame-pointer
Peter
--
Peter S. Mazinger
On Tue, Nov 15, 2005 at 09:01:21PM +0100, Peter S. Mazinger wrote:
> I meant exactly this, gcc supports -fno-stack-protector (although gcc
> defaults to no-ssp), so -fno-stack-protector-all should be there too
Why? What option would it perform?
r~
On Tue, 2005-11-15 at 12:01, Peter S. Mazinger wrote:
> I wanted to only know if there is a configuration/scenario where this
> really worked.
I haven't been involved with the stack protector development or usage,
but as far as I know, it works unless some one reports a bug, and the
only bug I c
On Tue, 15 Nov 2005, James E Wilson wrote:
> On Mon, 2005-11-14 at 22:45, Peter S. Mazinger wrote:
> > I have really hoped that someone here can duplicate it in any environment
>
> In that case, I'd suggest creating a bugzilla bug report. The gcc list
> is really more of a self-help list for gc
On Mon, 2005-11-14 at 22:45, Peter S. Mazinger wrote:
> I have really hoped that someone here can duplicate it in any environment
In that case, I'd suggest creating a bugzilla bug report. The gcc list
is really more of a self-help list for gcc developers. If you want to
try to debug the problem
:
Program received signal SIGSEGV, Segmentation fault.
main () at tes.c:3
3 int main () {
>bt
#0 main () at tes.c:3
allowing it to core dump and running gdb against the core
#... 0x000 in ?? ()
finally
Error accessing memory address 0xc000: No such file or directory
The same buil
this should also influence the -fstack-protector behaviour, but
that seems
to be OK.
__builtin_trap is used as I can see only if a vulnerability is
found, this
happens though on a simple hello world.
Aaah. You'll probably need to step through the program in a debugger
then and find out
On Mon, 14 Nov 2005, Eric Christopher wrote:
> >
> >> apps built w/ -fstack-protector-all segfault
> >
> > You will have to give us more info. Most gcc developers probably
> > don't have a copy of UClibc, and plus it sounds like you have made
> &g
On Mon, 14 Nov 2005, Jim Wilson wrote:
> Peter S. Mazinger wrote:
> > -fno-stack-protector-all is not recognised/implemented
>
> You could just submit this as a bug report into bugzilla.
>
> > apps built w/ -fstack-protector-all segfault
>
> You will have t
apps built w/ -fstack-protector-all segfault
You will have to give us more info. Most gcc developers probably
don't have a copy of UClibc, and plus it sounds like you have made
gcc changes that weren't included in your message. So there isn't
much we can do here exce
1 - 100 of 109 matches
Mail list logo
