I’m k B
Sent from my iPhone
W I’maI hope w
S
> On 25-Jan-2022, at 9:38 AM, Kris Andersen via Gcc wrote:
>
> The %m format specifier is a documented feature of syslog, but gcc gives a
> warning when -Wpedantic is used. Is this a bug?
>
> For example, the program:
>
> #include
> int main(void)
&
The %m format specifier is a documented feature of syslog, but gcc gives a
warning when -Wpedantic is used. Is this a bug?
For example, the program:
#include
int main(void)
{
syslog(LOG_ERR, "%m");
return 0;
}
gives:
warning: ISO C does not support the ‘%m’ gnu_printf format
hi,my honeyboy. i was seen you in Xvidieos yesterday and i waunt to fucc you.
My name Dorcas
I create some account With my personal photo.
I`ll Wait youth messages.
my second nickname : Campbell483.
Please Find my account...
bered after a call, it doesn't need to be restored, so you can use
pop {regs,PC} to return).
Cortex-M hardware will automatically save/restore R0-R3, R12, LR, PC, PSR
on interrupts. That perfectly matches the caller-saves and clobbered
registers, so there is no potential bug.
Wilco
On 16/11/17 17:54, Vitalijus Jefišovas wrote:
> On Cortex-M mcu’s, when interrupt happens, NVIC copies r0-r3 and couple
> other registers onto the psp stack, and then jumps to interrupt routine,
> when it finishes, NVIC restores these registers, and jumps back to user’s
> functio
Vitalijus Jefišovas kirjoitti 16.11.2017 klo 18:54:
On Cortex-M mcu’s, when interrupt happens, NVIC copies r0-r3 and couple
other registers onto the psp stack, and then jumps to interrupt routine,
when it finishes, NVIC restores these registers, and jumps back to user’s
function.
What is
> On Nov 16, 2017, at 11:54 AM, Vitalijus Jefišovas wrote:
>
> On Cortex-M mcu’s, when interrupt happens, NVIC copies r0-r3 and couple
> other registers onto the psp stack, and then jumps to interrupt routine,
> when it finishes, NVIC restores these registers, and jumps
On Cortex-M mcu’s, when interrupt happens, NVIC copies r0-r3 and couple
other registers onto the psp stack, and then jumps to interrupt routine,
when it finishes, NVIC restores these registers, and jumps back to user’s
function.
What is happening under the hood, NVIC only stacks 4 registers, r0
Hi Boris,
On Sat, Aug 12, 2017 at 05:53:44PM +0200, Boris Kolpackov wrote:
> Segher Boessenkool writes:
>
> > Patches should go to gcc-patches.
>
> Ok, will keep in mind for future (seeing that we have a discussion
> already it probably doesn't make sense to move this patch).
Please do move it
outdated generated headers that now trigger errors
+ (for example, with #error) which would be resolved by re-generating
+ them. In a sense, this complements -MG. */
+ if (cpp_opts->deps.style != DEPS_NONE)
{
/* If -M or -MM was seen without -MF, default output to the
output stream. */
Joseph Myers writes:
> I suppose a question for the present proposal would be making sure any
> dependencies generated in this case do not include dependencies on files
> that don't exist (so #include "some-misspelling.h" doesn't create any sort
> of dependency on such a header).
Good point.
On Wed, 9 Aug 2017, Jeff Law wrote:
> This directly reverts part of Joseph's changes from 2009. I'd like to
> hear from him on this change.
The point of those changes was to make cpplib diagnostics use the
compiler's diagnostic machinery rather than a separate set of diagnostic
machinery in c
On 08/06/2017 01:59 AM, Boris Kolpackov wrote:
> Hi,
>
> Currently GCC does not write extracted header dependency information
> if there are errors. However, this can be useful when dealing with
> outdated generated headers that trigger errors which would have been
> resolved if we could update it
Hi!
Patches should go to gcc-patches.
Just a trivial remark:
> --- gcc/c-family/c-opts.c (revision 250514)
> +++ gcc/c-family/c-opts.c (working copy)
> @@ -1152,8 +1152,11 @@
> {
>FILE *deps_stream = NULL;
>
> - /* Don't write the deps file if there are errors. */
> - if (cpp_o
andling outdated generated headers that now trigger errors
+ (for example, with #error) that would be resolved by re-generating
+ them. In a sense this complements -MG. */
+ if (cpp_opts->deps.style != DEPS_NONE)
{
/* If -M or -MM was seen without -MF, default output to the
output stream. */
Hi,
I notice that, libgcc has fp emulation libraries written in C for
armv6-m architecture which is quite big in size. Also I see that other
architecture like armv7-m has these libraries written in assembly for
smaller size lib.
I wanted to know, is there anybody working on this feature supporting
Devlet TeÅvikleri Bilgi Hattı: Ä°stanbul: 0212 586 50 67 - Mobil Ä°letiÅim: 0532
332 32 99
DIÅTÄ°CARETYÃNETÄ°MÄ°
20 Nisan Cumartesi Yeni TeÅvik Kanunu ve Bütün Devlet TeÅvikleri ile AB
Hibeleri EÄitimi
21 Nisan Pazar Yatırım TeÅvik Belgesi ve Yatırım Fizibilitesi HazÄ
Devlet TeÅvikleri Bilgi Hattı: Ä°stanbul: 0212 586 50 67 - Mobil Ä°letiÅim: 0532
332 32 99
DIÅTÄ°CARETYÃNETÄ°MÄ°
20 Nisan Cumartesi Yeni TeÅvik Kanunu ve Bütün Devlet TeÅvikleri ile AB
Hibeleri EÄitimi
21 Nisan Pazar Yatırım TeÅvik Belgesi ve Yatırım Fizibilitesi HazÄ
M
iPhoneから送信
iPhoneから送信
M
Subject: ICE when calculate insn latency for armv7e-m arch in O2 level
>
> Greta,
>
> Since this checkin, GCC ICE when build fix-point library with
> -march=armv7e-m -O2. Reduced test case at
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53859
>
> This is a show-stop
Greta,
Since this checkin, GCC ICE when build fix-point library with
-march=armv7e-m -O2. Reduced test case at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53859
This is a show-stopper to cortex-m4 target.
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188742
Log:
The main func
Jakub Jelinek wrote:
> On Mon, Jul 04, 2011 at 03:49:58PM +0200, Michael Matz wrote:
>> > But you said the operand is an int sized memory, while you expect
>> > 4 times as big data with different alignment.
>> > So you want "m"(*(__m128d *)) (or "m
Hi,
On Mon, 4 Jul 2011, Jakub Jelinek wrote:
> No, what you can get out of that is e.g. optimizing away otherwise unneeded
> large variable.
> Consider:
> static const int i[131072] = { 1, 2, 3, 4, 5 };
> void foo (void)
> {
> __asm volatile ("" : : "m&qu
On Mon, Jul 04, 2011 at 03:49:58PM +0200, Michael Matz wrote:
> > But you said the operand is an int sized memory, while you expect
> > 4 times as big data with different alignment.
> > So you want "m"(*(__m128d *)) (or "m"(*(__m128i *)) ).
>
>
Hi,
On Fri, 1 Jul 2011, Jakub Jelinek wrote:
> > GCC turns this into:
> > "movaps%0, %%xmm0
> > shufps$27, %%xmm0, %%xmm0
> > movaps%1, %%xmm5
> > movaps %%xmm5, %%xmm6
> > " : : "m" costab_mmx[
question can be found in mplayer/mp3lib/dct64_sse.c
>>
>> "movaps %0, %%xmm0\n\t"
>> "shufps $27, %%xmm0, %%xmm0\n\t"
>> "movaps %1, %%xmm5\n\t"
>> "movaps %%xmm5, %%xmm6\n\t"
uot;movaps%0, %%xmm0\n\t"
> "shufps$27, %%xmm0, %%xmm0\n\t"
> "movaps%1, %%xmm5\n\t"
> "movaps%%xmm5, %%xmm6\n\t"
> :
> :"m"(*costab), "m"(*)
>
> where n
"movaps%1, %%xmm5\n\t"
"movaps%%xmm5, %%xmm6\n\t"
:
:"m"(*costab), "m"(*)
where is
static const int [4] __attribute__((aligned(16))) = { 1 << 31, 1
<< 31, 1 << 31, 1 << 31 };
GCC tur
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 $
On 6/20/07, Ben Elliston <[EMAIL PROTECTED]> wrote:
To now answer my own question (for the benefit of others): the CC1_SPEC
string can include the sequence %
This is not a good way, the best way is to create a dumby -moption in
the target.opt file so you get the documentation with --help.
-- Pi
On Wed, 2007-06-20 at 10:44 +1000, Ben Elliston wrote:
> I have a -m option that I am handling in a LIB_SPEC that I do not want
> passed down to cc1. It seems that by default, the driver passes all -m
> options to cc1. Is there a way to prevent that on a per-option basis?
To now answ
I have a -m option that I am handling in a LIB_SPEC that I do not want
passed down to cc1. It seems that by default, the driver passes all -m
options to cc1. Is there a way to prevent that on a per-option basis?
Thanks, Ben
On Tue, Feb 27, 2007 at 12:30:16PM +0800, Zuxy Meng wrote:
> Hi,
>
> -march=native choose pentium4 instead of pentium-m for Pentium M processors
> (see config/i386/driver-i386.c)? Is this intentional or a typo?
>
It is because Pentium M implements Pentium instructions. You sh
Zuxy Meng wrote:
Hi,
-march=native choose pentium4 instead of pentium-m for Pentium M processors
(see config/i386/driver-i386.c)? Is this intentional or a typo?
I think the reason is that Intel changed completely the
microarchitecture (going back to something that actually is more similar
Hi,
-march=native choose pentium4 instead of pentium-m for Pentium M processors
(see config/i386/driver-i386.c)? Is this intentional or a typo?
--
Zuxy
On Fri, Dec 01, 2006 at 06:43:46AM -0800, H. J. Lu wrote:
> On Fri, Dec 01, 2006 at 03:36:59AM -0600, Ryan Hill wrote:
> > Currently, the way the native CPU detection code in driver-i386.c
> > is set up, using -m{arch,tune}=native with an Intel Core Duo (*not
> > Core 2 Duo*)
On Fri, Dec 01, 2006 at 03:36:59AM -0600, Ryan Hill wrote:
> Currently, the way the native CPU detection code in driver-i386.c
> is set up, using -m{arch,tune}=native with an Intel Core Duo (*not
> Core 2 Duo*) processor will result in -m{arch,tune}=prescott. Is this
> the correct
Currently, the way the native CPU detection code in driver-i386.c
is set up, using -m{arch,tune}=native with an Intel Core Duo (*not
Core 2 Duo*) processor will result in -m{arch,tune}=prescott. Is this
the correct setting for this chip? There seems to be a lot of confusion
across the net as to
On Feb 26, 2005, at 8:01 AM, [EMAIL PROTECTED] wrote:
gcc -XLinker -M test.c 2>test.map
would output some usful information about locating
function to lib and ...
The detail analyze of them would be very useful.
Where can I find some introduce document about them?
This list isn't
for example,
I want to locate the which lib is linked for fprintf
v===test.c===v
#include
main()
{
doit();
}
doit()
{
fprintf(stderr,"==");
}
^^^
I run
gcc -Xlinker -M test.c 2>map
Hi,
gcc -XLinker -M test.c 2>test.map
would output some usful information about locating
function to lib and ...
The detail analyze of them would be very useful.
Where can I find some introduce document about them?
Thanks in advance.
gan
__
Balaji S wrote:
Can you please tell me how to get these attributes while emitting RTL?
My requirement is, need the newly introduced attributes while doing
memory access.
It depends on what you are doing, and you might need to write new code
to be able to do it. See for instance TARGET_ENCODE_SE
_On 10-Feb-2005 08:36, James E Wilson san wrote_:
Balaji S wrote:
I have introduced m/c dependent attributes and handling it's semantics
via the attribute's handler. And i want to use these attributes during
assembly printing from RTL. How to get these attributes?
This isn't how
59 matches
Mail list logo
