Each so that the musterfile.
To trySince you set up your.
reload question - the compiler fails to find register to spill in a class
Hi, I'm developing a gcc based compiler and in a certain scenario I get the following reload crash: "error: unable to find a register to spill in class 'AB_REGS'" I looked into it and it looks like it happens when all the AB_REGS registers are taken as function arguments, and the prefered class in a certain insn for a pseudo register is AB_REGS. This despite the fact that an alternative that includes GENERAL_REGS (r) has been chosen for that insn. Why does reload crash and doesn't try to use other registers from GENERAL_REGS class? What is the correct way to handle this problem? Thanks, Tomer
RE: internal compiler error: Segmentation fault
Hi, "J. Finch" wrote on 10.01.2008 15:23:56: > > on the issue as stated in the subject regarding x86_64-pc-mingw64, I > have downloaded MS debugger as suggested by FX, and I attach the > logs where command "p" is stepping. > > fortran Program, c.f90, for test, one statement only > [program begin] > end > [program end] > > The command "cdb gfortran c.f90" output "without.log". This one is good. > The command "cdb gfortran -O1 c.f90" output the log "with.log" . > > *** attention: attachment may break long line into two*** If you > need further information, please let me know. > > > [without.log] > Symbol search path is: *** Invalid *** > > * Symbol loading may be unreliable without a symbol search path. * > * Use .symfix to have the debugger choose a symbol path. * > * After setting your symbol path, use .reload to refresh symbol locations. * > > Executable search path is: > ModLoad: `0040 `0043c000 image`0040 > ModLoad: `77ec `77ff9000 ntdll.dll > ModLoad: `77d4 `77eb3000 C: > \WINDOWS\system32\kernel32.dll > ModLoad: 07ff`7fc0 07ff`7fc86000 C:\WINDOWS\system32\msvcrt.dll > ModLoad: `77c2 `77d2c000 C:\WINDOWS\system32\USER32.dll > ModLoad: 07ff`7fc9 07ff`7fd2c000 C:\WINDOWS\system32\GDI32.dll > (8b0.5b4): Break instruction exception - code 8003 (first chance) > *** ERROR: Symbol file could not be found. Defaulted to export > symbols for ntdll.dll - > ntdll!DbgBreakPoint: > `77ef2aa0 cc int 3 > 0:000> p > ntdll!DbgBreakPoint+0x1: > `77ef2aa1 c3 ret > 0:000> p > ntdll!LdrInitShimEngineDynamic+0xcbc: > `77f1bbcc 8b95bc00mov edx,dword ptr [rbp+0BCh] > ss:07ff`fffd80bc=0070 > 0:000> p > ntdll!LdrInitShimEngineDynamic+0xcc2: > `77f1bbd2 d1eashr edx,1 > 0:000> p > ntdll!LdrInitShimEngineDynamic+0xcc4: > `77f1bbd4 80e201 and dl,1 > 0:000> p > ntdll!LdrInitShimEngineDynamic+0xcc7: > `77f1bbd7 8815bdb30800mov byte ptr [ntdll! > NlsMbOemCodePageTag+0x882 (`77fa6f9a)],dl ds:`77fa6f9a=00 > 0:000> p > ntdll!LdrInitShimEngineDynamic+0xccd: > `77f1bbdd e9939bfbff jmp ntdll! > CsrCaptureMessageBuffer+0x3b5 (`77ed5775) > 0:000> p > ntdll!CsrCaptureMessageBuffer+0x3b5: > `77ed5775 488bb4241001 mov rsi,qword ptr [rsp+110h] > ss:`0022f7e0= > 0:000> p > ntdll!CsrCaptureMessageBuffer+0x3bd: > `77ed577d 4885f6 testrsi,rsi > 0:000> p > ntdll!CsrCaptureMessageBuffer+0x3c0: > `77ed5780 0f855c640400jne ntdll! > LdrInitShimEngineDynamic+0xcd2 (`77f1bbe2) [br=0] > 0:000> p > ntdll!CsrCaptureMessageBuffer+0x3c6: > `77ed5786 498bcd mov rcx,r13 > 0:000> p > ntdll!CsrCaptureMessageBuffer+0x3c9: > `77ed5789 e852e2 callntdll! > CsrClientConnectToServer+0x2f0 (`77ed39e0) > 0:000> p > ntdll!CsrCaptureMessageBuffer+0x3ce: > `77ed578e 4533e4 xor r12d,r12d > 0:000> p > ntdll!CsrCaptureMessageBuffer+0x3d1: > `77ed5791 498bcf mov rcx,r15 > 0:000> p > ntdll!CsrCaptureMessageBuffer+0x3d4: > `77ed5794 e8d78f callntdll! > RtlDeregisterWait+0x640 (`77ede770) > 0:000> p > ModLoad: 07ff`7d50 07ff`7d539000 C:\WINDOWS\system32\IMM32.DLL > ModLoad: 07ff`7fee 07ff`7ffe5000 C: > \WINDOWS\system32\ADVAPI32.dll > ModLoad: 07ff`7fd3 07ff`7fec9000 C:\WINDOWS\system32\RPCRT4.dll > ModLoad: 07ff`7e9c 07ff`7e9e2000 C:\WINDOWS\system32\Secur32.dll > ModLoad: 07ff`6930 07ff`6930d000 C:\WINDOWS\system32\LPK.DLL > ModLoad: 07ff`78e8 07ff`78f0e000 C:\WINDOWS\system32\USP10.dll > ntdll!CsrCaptureMessageBuffer+0x3d9: > `77ed5799 85c0testeax,eax > 0:000> p > ntdll!CsrCaptureMessageBuffer+0x3db: > `77ed579b 8bd8mov ebx,eax > 0:000> p > ntdll!CsrCaptureMessageBuffer+0x3dd: > `77ed579d 0f8861640400js ntdll! > LdrInitShimEngineDynamic+0xcf4 (`77f1bc04) [br=0] > 0:000> p > ntdll!CsrCaptureMessageBuffer+0x3e3: > `77ed57a3 833d86ea0c cmp dword ptr [ntdll! > pow+0x2230 (`77fa4230)],0 ds:`77fa4230= > 0:000> p > ntdll!CsrCaptureMessageBuffer+0x3ea: > `77ed57aa 0f858e640400jne ntdll! > LdrInitShimEngineDynamic+0xd2e (`77f1bc3e) [br=0] > 0:000> p > ntdll!CsrCaptureMessageBuffer+0x3f0: > `77ed57b0 488b853002 mov rax,qword ptr [rbp+230h] > ss:07ff`fffd8230= > 0:000> p > ntdll!CsrCaptureMessageBuffer+0x3f7: > `77ed57b7 4885c0 testrax,rax > 0:000>
RE: internal compiler error: Segmentation fault
> > This looks fine. What is the call stack looks like? And how does the > function calling ntdll looks like? > I think, you should step on an "int 3". Because you simply debug the > exception handling routine itself. > Hi, Kai: I attach the stack in the following: C:\temp\fortran>cdb gfortran -O1 c.f90 Microsoft (R) Windows Debugger Version 6.8.0004.0 AMD64 Copyright (c) Microsoft Corporation. All rights reserved. CommandLine: gfortran -O1 c.f90 Symbol search path is: *** Invalid *** * Symbol loading may be unreliable without a symbol search path. * * Use .symfix to have the debugger choose a symbol path. * * After setting your symbol path, use .reload to refresh symbol locations. * Executable search path is: ModLoad: `0040 `0043c000 image`0040 ModLoad: `77ec `77ff9000 ntdll.dll ModLoad: `77d4 `77eb3000 C:\WINDOWS\system32\kernel32.dll ModLoad: 07ff`7fc0 07ff`7fc86000 C:\WINDOWS\system32\msvcrt.dll ModLoad: `77c2 `77d2c000 C:\WINDOWS\system32\USER32.dll ModLoad: 07ff`7fc9 07ff`7fd2c000 C:\WINDOWS\system32\GDI32.dll (a20.a24): Break instruction exception - code 8003 (first chance) *** ERROR: Symbol file could not be found. Defaulted to export symbols for ntdll.dll - ntdll!DbgBreakPoint: `77ef2aa0 cc int 3 0:000> g ModLoad: 07ff`7d50 07ff`7d539000 C:\WINDOWS\system32\IMM32.DLL ModLoad: 07ff`7fee 07ff`7ffe5000 C:\WINDOWS\system32\ADVAPI32.dll ModLoad: 07ff`7fd3 07ff`7fec9000 C:\WINDOWS\system32\RPCRT4.dll ModLoad: 07ff`7e9c 07ff`7e9e2000 C:\WINDOWS\system32\Secur32.dll ModLoad: 07ff`6930 07ff`6930d000 C:\WINDOWS\system32\LPK.DLL ModLoad: 07ff`78e8 07ff`78f0e000 C:\WINDOWS\system32\USP10.dll c.f90: In function 'MAIN__': c.f90:1: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. ntdll!ZwTerminateProcess+0xa: `77ef0caa c3 ret 0:000> kb *** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\WINDOWS\system32\kernel32.dll - RetAddr : Args to Child : Call Site `77d5a329 : `0001 `0001 `0001 ` : ntdll!ZwTerminateProcess+0xa *** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\WINDOWS\system32\msvcrt.dll - 07ff`7fc4069b : ` `00428030 ` `4060 : kernel32!ExitProcess+0x59 07ff`7fc40863 : ` ` ` ` : msvcrt!strerror+0x3beb *** ERROR: Module load completed but symbols could not be loaded for image`0040 `0040141d : `0003 `003d3590 ` `00419a10 : msvcrt!initterm+0x193 `0003 : `003d3590 ` `00419a10 ` : image_0040+0x141d `003d3590 : ` `00419a10 ` ` : 0x3 ` : `00419a10 ` ` ` : 0x3d3590 `00419a10 : ` ` ` ` : 0x0 ` : ` ` ` ` : image_0040+0x19a10 ` : ` ` ` ` : 0x0 ` : ` ` ` ` : 0x0 ` : ` ` ` ` : 0x0 ` : ` ` ` ` : 0x0 ` : ` ` ` ` : 0x0 ` : ` ` ` ` : 0x0 ` : ` ` ` ` : 0x0 ` : ` ` ` ` : 0x0 ` : ` ` ` ` : 0x0 ` : ` ` ` ` : 0x0 ` : ` ` ` ` : 0x0 0:000> _ Share life as it happens with the new Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_
RE: internal compiler error: Segmentation fault
Hi, stack before and after segmentation fault is as: .. .. ntdll!KiUserApcDispatcher+0x15: `77ef30a5 488bcc mov rcx,rsp 0:000> p ntdll!KiUserApcDispatcher+0x18: `77ef30a8 b201mov dl,1 0:000> k Child-SP RetAddr Call Site `0022fab0 `77d59620 ntdll!KiUserApcDispatcher+0x18 `0022ffa8 ` kernel32!BaseProcessStart 0:000> p ntdll!KiUserApcDispatcher+0x1a: `77ef30aa e861dd callntdll!NtContinue (`77ef0e10) 0:000> k Child-SP RetAddr Call Site `0022fab0 `77d59620 ntdll!KiUserApcDispatcher+0x1a `0022ffa8 ` kernel32!BaseProcessStart 0:000> p c.f90: In function 'MAIN__': c.f90:1: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. ntdll!ZwTerminateProcess+0xa: `77ef0caa c3 ret 0:000> k Child-SP RetAddr Call Site `0022fd08 `77d5a329 ntdll!ZwTerminateProcess+0xa *** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\WINDOWS\system32\msvcrt.dll - `0022fd10 07ff`7fc4069b kernel32!ExitProcess+0x59 `0022fe60 07ff`7fc40863 msvcrt!strerror+0x3beb *** ERROR: Module load completed but symbols could not be loaded for image`0040 `0022fe90 `0040141d msvcrt!initterm+0x193 `0022fed0 `0003 image_0040+0x141d `0022fed8 `003d3590 0x3 `0022fee0 ` 0x3d3590 `0022fee8 `00419a10 0x0 `0022fef0 ` image_0040+0x19a10 `0022fef8 ` 0x0 `0022ff00 ` 0x0 `0022ff08 ` 0x0 `0022ff10 ` 0x0 `0022ff18 ` 0x0 `0022ff20 ` 0x0 `0022ff28 ` 0x0 `0022ff30 ` 0x0 `0022ff38 ` 0x0 `0022ff40 ` 0x0 `0022ff48 ` 0x0 0:000> _ Get the power of Windows + Web with the new Windows Live. http://www.windowslive.com?ocid=TXT_TAGHM_Wave2_powerofwindows_012008
RE: internal compiler error: Segmentation fault
Hi,
"J. Finch" wrote on 10.01.2008 16:31:38:
Thank you very much for your dumps, but you should use on runtime the
option '-dH' option to enforce that you reach the point, where the
exception is caused.
> stack before and after segmentation fault is as:
>
>
> ..
> ..
> ntdll!KiUserApcDispatcher+0x15:
> `77ef30a5 488bcc mov rcx,rsp
> 0:000> p
> ntdll!KiUserApcDispatcher+0x18:
> `77ef30a8 b201mov dl,1
> 0:000> k
> Child-SP RetAddr Call Site
> `0022fab0 `77d59620 ntdll!KiUserApcDispatcher+0x18
> `0022ffa8 ` kernel32!BaseProcessStart
> 0:000> p
> ntdll!KiUserApcDispatcher+0x1a:
> `77ef30aa e861dd callntdll!NtContinue
(`77ef0e10)
> 0:000> k
> Child-SP RetAddr Call Site
> `0022fab0 `77d59620 ntdll!KiUserApcDispatcher+0x1a
> `0022ffa8 ` kernel32!BaseProcessStart
> 0:000> p
> c.f90: In function 'MAIN__':
> c.f90:1: internal compiler error: Segmentation fault
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See for instructions.
> ntdll!ZwTerminateProcess+0xa:
> `77ef0caa c3 ret
> 0:000> k
> Child-SP RetAddr Call Site
> `0022fd08 `77d5a329 ntdll!ZwTerminateProcess+0xa
> *** ERROR: Symbol file could not be found. Defaulted to export
> symbols for C:\WINDOWS\system32\msvcrt.dll -
> `0022fd10 07ff`7fc4069b kernel32!ExitProcess+0x59
> `0022fe60 07ff`7fc40863 msvcrt!strerror+0x3beb
> *** ERROR: Module load completed but symbols could not be loaded for
> image`0040
> `0022fe90 `0040141d msvcrt!initterm+0x193
> `0022fed0 `0003 image_0040+0x141d
> `0022fed8 `003d3590 0x3
> `0022fee0 ` 0x3d3590
> `0022fee8 `00419a10 0x0
> `0022fef0 ` image_0040+0x19a10
> `0022fef8 ` 0x0
> `0022ff00 ` 0x0
> `0022ff08 ` 0x0
> `0022ff10 ` 0x0
> `0022ff18 ` 0x0
> `0022ff20 ` 0x0
> `0022ff28 ` 0x0
> `0022ff30 ` 0x0
> `0022ff38 ` 0x0
> `0022ff40 ` 0x0
> `0022ff48 ` 0x0
> 0:000>
Cheers,
i.A. Kai Tietz
| (\_/) This is Bunny. Copy and paste Bunny
| (='.'=) into your signature to help him gain
| (")_(") world domination.
--
OneVision Software Entwicklungs GmbH & Co. KG
Dr.-Leo-Ritter-Straße 9 - 93049 Regensburg
Tel: +49.(0)941.78004.0 - Fax: +49.(0)941.78004.489 - www.OneVision.com
Commerzbank Regensburg - BLZ 750 400 62 - Konto 6011050
Handelsregister: HRA 6744, Amtsgericht Regensburg
Komplementärin: OneVision Software Entwicklungs Verwaltungs GmbH
Dr.-Leo-Ritter-Straße 9 – 93049 Regensburg
Handelsregister: HRB 8932, Amtsgericht Regensburg - Geschäftsführer:
Ulrike Döhler, Manuela Kluger
DECL_FIELD_CONTEXT woes
Hi all,
I'm going on brutalizing GIMPLE code to make it more suitable for CIL emition in
the CLI be/fe branch and I've stumbled across something which looks really weird.
When working with types I always assumed that if 't' is a RECORD_TYPE,
UNION_TYPE or QUAL_UNION_TYPE then calling DECL_FIELD_CONTEXT () on its fields
yields 't' itself. Chasing a weird bug I had in the test suite I ended up with a
case where this wasn't true. This happens in:
gcc.c-torture/execute/ieee/fp-cmp-4.c. I've pasted only the relevant code:
int
main()
{
struct try
{
FLOAT x, y;
unsigned unord : 1;
unsigned lt : 1;
unsigned le : 1;
unsigned gt : 1;
unsigned ge : 1;
unsigned lg : 1;
};
static struct try const data[] =
{
{ NAN, NAN, 1, 0, 0, 0, 0, 0 },
{ 0.0, NAN, 1, 0, 0, 0, 0, 0 },
{ NAN, 0.0, 1, 0, 0, 0, 0, 0 },
{ 0.0, 0.0, 0, 0, 1, 0, 1, 0 },
{ 1.0, 2.0, 0, 1, 1, 0, 0, 1 },
{ 2.0, 1.0, 0, 0, 0, 1, 1, 1 },
};
const int n = sizeof(data) / sizeof(data[0]);
int i;
for (i = 0; i < n; ++i)
{
test_isunordered (data[i].x, data[i].y, data[i].unord);
test_isless (data[i].x, data[i].y, data[i].lt);
test_islessequal (data[i].x, data[i].y, data[i].le);
test_isgreater (data[i].x, data[i].y, data[i].gt);
test_isgreaterequal (data[i].x, data[i].y, data[i].ge);
test_islessgreater (data[i].x, data[i].y, data[i].lg);
}
exit (0);
}
Here's the catch, when compiling the main function a RECORD_TYPE is built for
representing 'struct try' (obviously). Then an helper function is generated
which seems to be used for initializing the 'data' array (I think it's called
COBJ?Init). A new type still named 'struct try' is used in the COMPONENT_REFs of
this function but this type has a different TYPE_UID from the 'struct try' used
in main. Since the original type was local to main this makes sense. However
this new type shares the fields with the old one i.e. calling DECL_FIELD_CONTEXT
() on its fields doesn't yield itself but another type (the old one used in main).
Is this correct? The documentation in of DECL_FIELD_CONTEXT () in tree.h
doesn't state anything about it which left me kind of confused...
Gabriele
RE: DECL_FIELD_CONTEXT woes
On 10 January 2008 16:12, Gabriele SVELTO wrote:
> int
> main()
> {
>struct try
>{
> FLOAT x, y;
> unsigned unord : 1;
> unsigned lt : 1;
> unsigned le : 1;
> unsigned gt : 1;
> unsigned ge : 1;
> unsigned lg : 1;
>};
>
>static struct try const data[] =
>{
> { NAN, NAN, 1, 0, 0, 0, 0, 0 },
> { 0.0, NAN, 1, 0, 0, 0, 0, 0 },
> { NAN, 0.0, 1, 0, 0, 0, 0, 0 },
> { 0.0, 0.0, 0, 0, 1, 0, 1, 0 },
> { 1.0, 2.0, 0, 1, 1, 0, 0, 1 },
> { 2.0, 1.0, 0, 0, 0, 1, 1, 1 },
>};
> A new type still named 'struct try' is used in the COMPONENT_REFs of
> this function but this type has a different TYPE_UID from the 'struct try'
> used in main. Since the original type was local to main this makes sense.
But the array is local to main as well ...
> However this new type shares the fields with the old one i.e. calling
> DECL_FIELD_CONTEXT () on its fields doesn't yield itself but another type
> (the old one used in main).
Is this possibly because the new type is not "struct try" but "struct try
const"; it adds the const qualifier and refers back to the original "struct
try" for the fields?
cheers,
DaveK
--
Can't think of a witty .sigline today
Re: Allocating scratch register
Hi!
Am 09.01.2008 um 23:54 schrieb Ian Lance Taylor:
Boris Boesler <[EMAIL PROTECTED]> writes:
I'm trying to allocate a scratch register: write immediate constant
into scratch register r, write register r into memory
...
What is wrong with the code above?
There is nothing wrong with that code, but nothing is going to make
the compiler use it. Moves are special.
Yes, I can remember that constraints in a mov-insn can not be
resolved by other/additional mov-insns.
Ok, I rewrote my insns; there was a "mov"-insn with mode \in
{QI, HI, SI}:
(define_insn_and_split "movqi"
[(set (match_operand:QI 0 "reg_mem_operand" "=mr")
(match_operand:QI 1 "rim_operand" " mir"))
(clobber (match_scratch:QI 2 "=r"))
]
""
"#"
"&& reload_completed"
[(set (match_dup 2) (match_dup 1))
(set (match_dup 0) (match_dup 2))]
"")
;; help insns
(define_insn "mov_reg_by_store"
[(set (match_operand:I8I16 0 "memory_operand" "= m")
(match_operand:I8I16 1 "register_operand" " rAx"))]
""
"bla bla bla")
(define_insn "mov_reg_imm"
[(set (match_operand:I8I16 0 "register_operand" "=rAx, rAx, rAx")
(match_operand:I8I16 1 "immediate_operand" " I, i, rAx"))]
""
"some other bla bla bla")
These insns handle byte-accesses as expected. But now a previous
tests fail for something like ashift:SI(reg:SI, const_int:QI 5):
p.c:36: error: unrecognizable insn:
(insn 114 18 115 (set (scratch:QI)
(const_int 5 [0x5])) -1 (nil)
(nil))
I do not understand why this happens does not happen in my byte-
access example. So I added the two insns (I8I16 = {QI, HI}):
(define_insn "mov_to_scratch"
[(set (match_scratch:I8I16 0 "=r,r")
(match_operand:I8I16 1 "reg_imm_operand" " r,i"))]
""
"again bla bla bla")
(define_insn "mov_from_scratch"
[(set (match_operand:I8I16 0 "register_operand" "=r")
(match_scratch:I8I16 1" r"))]
""
"even more bla bla bla")
But now the compiler says:
p.c:36: error: insn does not satisfy its constraints:
(insn 114 18 115 (set (scratch:QI)
(const_int 5 [0x5])) 79 {movqi_to_scratch} (nil)
(nil))
p.c:36: internal compiler error: in final_scan_insn, at final.c:2382
The two insns in the dump file .shorten are:
(insn 114 18 115 (set (scratch:QI)
(const_int 5 [0x5])) 79 {movqi_to_scratch} (nil)
(nil))
(insn 115 114 19 (set (reg:QI 31 R31)
(scratch:QI)) 81 {movqi_from_scratch} (nil)
(nil))
I can't see what's wrong. I guess I don't understand that scratch-
stuff in gcc?
Thanks,
Boris
Re:
Life can be a different thing for you now! Why wait?!WE now happy to introduce to you a tatally different option to acquire your qualification online!Whatever your specialization is now obtaining your diploma degree becomes a reality. Lot's of people worldwide appreciated this unique opportunity of getting bachelors, PHs, and Masters through the net. And plus you now able to reach your aim almoust instantly.The missing brick is right there! Call us 1 206 888-2083 for 24/7. You can proudly grasp your diploma within days!
Re: DECL_FIELD_CONTEXT woes
Dave Korn wrote: On 10 January 2008 16:12, Gabriele SVELTO wrote: > [snip] > A new type still named 'struct try' is used in the COMPONENT_REFs of this function but this type has a different TYPE_UID from the 'struct try' used in main. Since the original type was local to main this makes sense. But the array is local to main as well ... But it's static so it needs to be initialized once before the function gets called AFAIK. gcc seems to be creating an artificial function for this task or at least that's how it looks. I've been working on gcc for only ~3 months so I might be badly wrong on this one. However this new type shares the fields with the old one i.e. calling DECL_FIELD_CONTEXT () on its fields doesn't yield itself but another type (the old one used in main). Is this possibly because the new type is not "struct try" but "struct try const"; it adds the const qualifier and refers back to the original "struct try" for the fields? Yes, TYPE_READONLY () returns 1 on the new type so I guess it's const. So is it normal that the two types share the fields so that you can end up with DECL_FIELD_CONTEXT (TYPE_FIELDS (type)) != type ? Does this always happen when gcc creates a 'derived' const type from another one? Thanks for the help, Gabriele
Re: Allocating scratch register
> Yes, I can remember that constraints in a mov-insn can not be > resolved by other/additional mov-insns. I think you're doing this the wrong way. You don't have a i->m mov instruction, so why are you pretending you do? Why aren't you doing this the same way as pretty much every other target? i.e.: (define_insn "*movqi_insn" [(set (match_operand:QI 0 "reg_mem_operand" "=r,m") (match_operand:QI 1 "rim_operand" " mi,r")) "" "mov %0,%1" ) (define_expand "movqi" [(set (match...) (match...)] "" " if (GET_CODE (operands[0]) == MEM) operands[1] = force_reg (QImode, operands[1]); " ) Plus the appropriate *_RELOAD_CLASS macros to keep reload happy. Paul
RE: DECL_FIELD_CONTEXT woes
On 10 January 2008 16:40, Gabriele SVELTO wrote: > Dave Korn wrote: >> On 10 January 2008 16:12, Gabriele SVELTO wrote: >> > > [snip] > > >>> A new type still named 'struct try' is used in the COMPONENT_REFs of >>> this function but this type has a different TYPE_UID from the 'struct try' >>> used in main. Since the original type was local to main this makes sense. >> >> But the array is local to main as well ... > > But it's static so it needs to be initialized once before the function gets > called AFAIK. gcc seems to be creating an artificial function for this task > or at least that's how it looks. I've been working on gcc for only ~3 > months so I might be badly wrong on this one. Yes, you're completely correct about the artificial initialiser function; I thought the compiler might output it as a nested function, but I don't know without checking. (But I've been working on gcc for only ~7 years so I might be badly wrong on this or indeed any other one. ;-P it's a big old pile of code!) >> Is this possibly because the new type is not "struct try" but "struct try >> const"; it adds the const qualifier and refers back to the original "struct >> try" for the fields? > > Yes, TYPE_READONLY () returns 1 on the new type so I guess it's const. Really you should use CP_TYPE_CONST_P to test this; IIUC, things can be const without being readonly (and perhaps even vice-versa), depending on which kind of section (.data/.rdata) they're allocated to. > So > is it normal that the two types share the fields so that you can end up with > DECL_FIELD_CONTEXT (TYPE_FIELDS (type)) != type ? Does this always happen > when gcc creates a 'derived' const type from another one? Thanks for the > help, I believe this is indeed gcc's bog-standard way of creating a qualified variant of an existing type. Note that you should see in this case that TYPE_MAIN_VARIANT (type) == DECL_FIELD_CONTEXT (TYPE_FIELDS (type)), I think. cheers, DaveK -- Can't think of a witty .sigline today
Re: DECL_FIELD_CONTEXT woes
Dave Korn wrote: On 10 January 2008 16:40, Gabriele SVELTO wrote: Yes, you're completely correct about the artificial initialiser function; I thought the compiler might output it as a nested function, but I don't know without checking. (But I've been working on gcc for only ~7 years so I might be badly wrong on this or indeed any other one. ;-P it's a big old pile of code!) I guess so, it redefined my concept of "large, complex project". Really you should use CP_TYPE_CONST_P to test this; IIUC, things can be const without being readonly (and perhaps even vice-versa), depending on which kind of section (.data/.rdata) they're allocated to. Thanks for the type, I was completely unaware of the existence of that macro. I believe this is indeed gcc's bog-standard way of creating a qualified variant of an existing type. Note that you should see in this case that TYPE_MAIN_VARIANT (type) == DECL_FIELD_CONTEXT (TYPE_FIELDS (type)), I think. Good to know, TYPE_MAIN_VARIANT () is exactly what I was looking for, unfortunately it's description in tree.def isn't exactly crystal clear :P Thank you very much Gabriele
Re: DECL_FIELD_CONTEXT woes
> "Gabriele" == Gabriele SVELTO <[EMAIL PROTECTED]> writes: Gabriele> Good to know, TYPE_MAIN_VARIANT () is exactly what I was Gabriele> looking for, unfortunately it's description in tree.def Gabriele> isn't exactly crystal clear :P Thank you very much This would be a great opportunity to improve the comment... Tom
RE: internal compiler error: Segmentation fault
Hi, Kai,
This is what you want, with -dH. If you need further information, please let me
know. Finch.
.
.
(8b8.8bc): Break instruction exception - code 8003 (first chance)
*** ERROR: Symbol file could not be found. Defaulted to export symbols for
ntdll.dll -
ntdll!DbgBreakPoint:
`77ef2aa0 cc int 3
0:000> p
ntdll!DbgBreakPoint+0x1:
`77ef2aa1 c3 ret
0:000> p
ntdll!LdrInitShimEngineDynamic+0xcbc:
`77f1bbcc 8b95bc00mov edx,dword ptr [rbp+0BCh]
ss:07ff`fffde0bc=0070
0:000> p
ntdll!LdrInitShimEngineDynamic+0xcc2:
`77f1bbd2 d1eashr edx,1
0:000> p
ntdll!LdrInitShimEngineDynamic+0xcc4:
`77f1bbd4 80e201 and dl,1
0:000> p
ntdll!LdrInitShimEngineDynamic+0xcc7:
`77f1bbd7 8815bdb30800mov byte ptr
[ntdll!NlsMbOemCodePageTag+0x882 (`77fa6f9a)],dl ds:`77fa6f9a=00
0:000> p
ntdll!LdrInitShimEngineDynamic+0xccd:
`77f1bbdd e9939bfbff jmp ntdll!CsrCaptureMessageBuffer+0x3b5
(`77ed5775)
0:000> p
ntdll!CsrCaptureMessageBuffer+0x3b5:
`77ed5775 488bb4241001 mov rsi,qword ptr [rsp+110h]
ss:`0022f7e0=
0:000> p
ntdll!CsrCaptureMessageBuffer+0x3bd:
`77ed577d 4885f6 testrsi,rsi
0:000> p
ntdll!CsrCaptureMessageBuffer+0x3c0:
`77ed5780 0f855c640400jne ntdll!LdrInitShimEngineDynamic+0xcd2
(`77f1bbe2) [br=0]
0:000> p
ntdll!CsrCaptureMessageBuffer+0x3c6:
`77ed5786 498bcd mov rcx,r13
0:000> p
ntdll!CsrCaptureMessageBuffer+0x3c9:
`77ed5789 e852e2 callntdll!CsrClientConnectToServer+0x2f0
(`77ed39e0)
0:000> p
ntdll!CsrCaptureMessageBuffer+0x3ce:
`77ed578e 4533e4 xor r12d,r12d
0:000> p
ntdll!CsrCaptureMessageBuffer+0x3d1:
`77ed5791 498bcf mov rcx,r15
0:000> p
ntdll!CsrCaptureMessageBuffer+0x3d4:
`77ed5794 e8d78f callntdll!RtlDeregisterWait+0x640
(`77ede770)
0:000> p
ModLoad: 07ff`7d50 07ff`7d539000 C:\WINDOWS\system32\IMM32.DLL
ModLoad: 07ff`7fee 07ff`7ffe5000 C:\WINDOWS\system32\ADVAPI32.dll
ModLoad: 07ff`7fd3 07ff`7fec9000 C:\WINDOWS\system32\RPCRT4.dll
ModLoad: 07ff`7e9c 07ff`7e9e2000 C:\WINDOWS\system32\Secur32.dll
ModLoad: 07ff`6930 07ff`6930d000 C:\WINDOWS\system32\LPK.DLL
ModLoad: 07ff`78e8 07ff`78f0e000 C:\WINDOWS\system32\USP10.dll
ntdll!CsrCaptureMessageBuffer+0x3d9:
`77ed5799 85c0testeax,eax
0:000> p
ntdll!CsrCaptureMessageBuffer+0x3db:
`77ed579b 8bd8mov ebx,eax
0:000> p
ntdll!CsrCaptureMessageBuffer+0x3dd:
`77ed579d 0f8861640400js ntdll!LdrInitShimEngineDynamic+0xcf4
(`77f1bc04) [br=0]
0:000> p
ntdll!CsrCaptureMessageBuffer+0x3e3:
`77ed57a3 833d86ea0c cmp dword ptr [ntdll!pow+0x2230
(`77fa4230)],0 ds:`77fa4230=
0:000> p
ntdll!CsrCaptureMessageBuffer+0x3ea:
`77ed57aa 0f858e640400jne ntdll!LdrInitShimEngineDynamic+0xd2e
(`77f1bc3e) [br=0]
0:000> p
ntdll!CsrCaptureMessageBuffer+0x3f0:
`77ed57b0 488b853002 mov rax,qword ptr [rbp+230h]
ss:07ff`fffde230=
0:000> p
ntdll!CsrCaptureMessageBuffer+0x3f7:
`77ed57b7 4885c0 testrax,rax
0:000> p
ntdll!CsrCaptureMessageBuffer+0x3fa:
`77ed57ba 0f85c7640400jne ntdll!LdrInitShimEngineDynamic+0xd77
(`77f1bc87) [br=0]
0:000> p
ntdll!CsrCaptureMessageBuffer+0x400:
`77ed57c0 4d85ed testr13,r13
0:000> p
ntdll!CsrCaptureMessageBuffer+0x403:
`77ed57c3 0f85c6640400jne ntdll!LdrInitShimEngineDynamic+0xd7f
(`77f1bc8f) [br=0]
0:000> p
ntdll!CsrCaptureMessageBuffer+0x409:
`77ed57c9 33c0xor eax,eax
0:000> p
ntdll!CsrCaptureMessageBuffer+0x40b:
`77ed57cb e92ee6 jmp ntdll!RtlSetThreadPoolStartFunc+0x10e
(`77ed3dfe)
0:000> p
ntdll!RtlSetThreadPoolStartFunc+0x10e:
`77ed3dfe 660f6fb424b002 movdqa xmm6,xmmword ptr [rsp+2B0h]
ss:`0022f980=
0:000> p
ntdll!RtlSetThreadPoolStartFunc+0x117:
`77ed3e07 eb4ajmp
ntdll!RtlSetThreadPoolStartFunc+0x163(`77ed3e53)
0:000> p
ntdll!RtlSetThreadPoolStartFunc+0x163:
`77ed3e53 488bb424f002 mov rsi,qword ptr [rsp+2F0h]
ss:`0022f9c0=
0:000> p
ntdll!RtlSetThreadPoolStartFunc+0x16b:
`77ed3e5b eb2ajmp
ntdll!RtlSetThreadPoolStartFunc+0x197(`77ed3e87)
0:000> p
ntdll!RtlSetThreadPoolStartFunc+0x197:
`77ed3e87 4c8bbc24c802 mov r15,qword ptr [rsp+2C8h]
ss:`0022f998={ntdll (`77ec)}
0:000> p
ntdll!RtlSetThreadPoolStartFunc+0x19f:
`77ed3e8f 4c8bb424d002 mov r14,qword ptr [rsp+2D0h]
s
Re: Patch Queue down
The main reason it is not hosted on the gcc servers is that it would require installation of ruby and ruby on rails. This has not been brought up on overseers before, and i do not know how people would feel about it. On Jan 10, 2008 2:01 AM, Manuel López-Ibáñez <[EMAIL PROTECTED]> wrote: > Hi, > > The patch queue http://www.dberlin.org/patches seems to be down. I > understand that Daniel is very busy and he is making some changes to > his site. However, I would argue that the queue was being quite > successful and provided a valuable service for many GCC developers. I > also provided a place to track patches that are waiting for stage1. > > Therefore, I was wondering if there is a reason it couldn't be hosted > in the GCC servers, along with bugzilla and the wiki. > > Cheers, > > Manuel. >
Re: [RFC] porting to gcc-4.3 docs
On Tue, 8 Jan 2008, Benjamin Kosnik wrote: > As such, I'd like to get a general indication from the greater GCC> community > as to this plan. Does this document seem like a good idea? > (Previously, we've left this kind of document to the user community. > Often the passage of time has not been particularly kind to these > links.) Is the suggested placement ok for everybody? > > If this is ok, some editing of duplicate info from changes.html should > take place. I volunteer to do this. Sweet, that's really a nice one. Thanks for stepping up with this, Benjamin. In addition to the link from the gcc-4.3/changes.html page I'd also like this to become a News item on the main page and we probably also will want to add a link from gcc-4.3/index.html itself. Don't be shy. :-) > And, finally, we'd need an ok from the wwwdocs head dude, Gerald. Looks good. I'll make a few comments below to avoid you getting hit by the automatic web pages checker, and I hope the various maintainers will also have a look at their respective domains but let's get this in! http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";> http://www.w3.org/1999/xhtml"; xml:lang="en" lang="en"> mailto:gcc@gcc.gnu.org"; /> http://gcc.gnu.org/favicon.ico"; /> http://gcc.gnu.org/gcc.css"; /> Most of this, and also the color settings in the tag and the footer you can omit. The wwwdocs machinery is taking care of it automagically. compilation or runt-time performance. Some of these changes are not ^^^ Typo. And, yes, I did spot the reference to naked users. But heck, we already knew those free software types all are old hippies, didn't we? C language issues Semantic change of extern inline I believe we'll want here? When compiling with -std=c99 or -std=gnu99, the extern Usually we write -std=c99, as you did later on. In addition, improvements to the GCC infrastructure allows several existing warning flags new ability to spot problematic code. Is this sentence okay? I'm not a native speaker, so I might miss a nuance here. trailing characters after a closing #endif are now hard errors. #endif To get rid of this error, remove any trailing text after an #endif, like so. #endif I'd say, take the input from Joe and Andrew into account and shoot ahead! Gerald
Re: [RFC] porting to gcc-4.3 docs
On Thu, Jan 10, 2008 at 11:26:29PM +0100, Gerald Pfeifer wrote: > In addition, improvements to the GCC infrastructure allows several > existing warning flags new ability to spot problematic code. > > Is this sentence okay? I'm not a native speaker, so I might miss a > nuance here. No, it's badly worded, but fixing it seems to be more than a matter of rephrasing. It's basically saying that existing warning flags will produce warnings, but I'd prefer to see something more specific. That is, what kinds of additional warnings should be expected?
Re: [RFC] porting to gcc-4.3 docs
On Thu, Jan 10, 2008 at 02:32:28PM -0800, Joe Buck wrote: > On Thu, Jan 10, 2008 at 11:26:29PM +0100, Gerald Pfeifer wrote: > > > In addition, improvements to the GCC infrastructure allows several > > existing warning flags new ability to spot problematic code. > > > > Is this sentence okay? I'm not a native speaker, so I might miss a > > nuance here. > > No, it's badly worded, but fixing it seems to be more than a matter of > rephrasing. It's basically saying that existing warning flags will > produce warnings, but I'd prefer to see something more specific. ^- s/warnings/additional warnings/, or maybe "fewer false positives" as well.
RE: [RFC] porting to gcc-4.3 docs
On 10 January 2008 22:47, Joe Buck wrote: > On Thu, Jan 10, 2008 at 02:32:28PM -0800, Joe Buck wrote: >> On Thu, Jan 10, 2008 at 11:26:29PM +0100, Gerald Pfeifer wrote: >> >>> In addition, improvements to the GCC infrastructure allows several >>> existing warning flags new ability to spot problematic code. >>> >>> Is this sentence okay? I'm not a native speaker, so I might miss a >>> nuance here. >> >> No, it's badly worded, but fixing it seems to be more than a matter of >> rephrasing. It's basically saying that existing warning flags will >> produce warnings, but I'd prefer to see something more specific. > >^- s/warnings/additional warnings/, or maybe "fewer false > positives" as well. " In addition, improvements to the GCC infrastructure allow improvements in the ability of several existing warnings to spot problematic code" ? cheers, DaveK -- Can't think of a witty .sigline today
Re: [RFC] porting to gcc-4.3 docs
On Thu, Jan 10, 2008 at 11:10:02PM -, Dave Korn wrote: > On 10 January 2008 22:47, Joe Buck wrote: > > > On Thu, Jan 10, 2008 at 02:32:28PM -0800, Joe Buck wrote: > >> On Thu, Jan 10, 2008 at 11:26:29PM +0100, Gerald Pfeifer wrote: > >> > >>> In addition, improvements to the GCC infrastructure allows several > >>> existing warning flags new ability to spot problematic code. > >>> > >>> Is this sentence okay? I'm not a native speaker, so I might miss a > >>> nuance here. > >> > >> No, it's badly worded, but fixing it seems to be more than a matter of > >> rephrasing. It's basically saying that existing warning flags will > >> produce warnings, but I'd prefer to see something more specific. > > > >^- s/warnings/additional warnings/, or maybe "fewer false > > positives" as well. > > " In addition, improvements to the GCC infrastructure allow > improvements in the ability of several existing warnings to > spot problematic code" ? I would start with Dave's fix, and then see if we can improve it somehow. Presumably this is talking about Manuel's work, at least in part?
Re: hard_regno_nregs == 0 ?
On Wed, 2008-01-09 at 15:38 -0500, DJ Delorie wrote: > [EMAIL PROTECTED] This macro must never return zero, even if a register > +cannot hold the requested mode - indicate that with HARD_REGNO_MODE_OK > +and/or CANNOT_CHANGE_MODE_CLASS instead. I think that HARD_REGNO_NREGS should not be returning zero, but I also think it is a moot point, as we shouldn't be using it on invalid subregs. Hence I like Paul's wording better than yours, but it appears not to be sufficient for your case, as your m32c is only fixing HARD_REGNO_NREGS to not return zero. It appears that the m32c port does define both HARD_REGNO_MODE_OK and CANNOT_CHANGE_MODE_CLASS, so it isn't clear what the problem is. I suspect that there may be another problem here. Unfortunately, I don't have a testcase I can use to look at this myself. Maybe if we found and fixed this other problem, Paul's wording would be correct again. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: hard_regno_nregs == 0 ?
IIRC, the bug happened building either libgcc or newlib. If you want to revert my latest patch in a local source tree and just try a build, it's likely to show you an example ;-)
Release Management
The GCC Steering Committee has appointed Jakub Jelinek, Joseph Myers, and Richard Guenther to help with GCC Release Management. It's a big job, and I haven't had as much time for it recently as I had in the past. Jakub, Joseph, and Richard all have tremendous GCC experience, and I think that having fresh perspective and additional bandwidth will be an excellent thing. We're going to be feeling our way a bit to see how best to divide and share responsibility. One immediate change: we're going to start rotating the responsibility of writing status reports for GCC, in the hope of getting more-frequent (hopefully weekly) reports and in the hope that having people with difference perspectives look at the bug lists will help to spot different trends. Also, any of the four of us will now be free to set priorities for defects in Bugzilla. (That's a natural thing to do when working on a status report.) If there's controversy, I'll make a final decision, but my expectation is that will be necessary very rarely. I plan to share and delegate more responsibility as we begin to enter the GCC 4.4 cycle. I'm very grateful that Jakub, Joseph, and Richard all agreed to help out in this way. Please join me in thanking and congratulating our new co-RMs! -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: -Wparentheses lumps too much together
> > Yes, I know beginners get confused by and/or precedence. But > > *every* language that I know of that has operator precedence places > > 'and' before 'or'. > > FWIW, Bourne shell doesn't, && and || have equal precedence there. > That's a bit off-topic though, as it's not an argument against your > actual proposition, but rather one for `sh -Wall'. ;-) > It's not entirely off-topic. Not all programmers are dedicated to a > specific language. It's customary to work on several different > languages, and keeping things like operator precedance straight in > your head between languages is not always easy. Things like -Wall are > a great help in making sure that you don't miss any of those > inter-language oddities. Just a note: Operator precedence is taught as logical AND comes before OR in logic courses. So it is a sort of a standard mathematical convention just like + and *. In fact, OR is even represented as a + in some notations. However it might not be practical to assume all programmers have a background in logic. -Rehno Lindeque
