search for: usb_bus

...LLVM > type "{ i32, [0 x float]}", for example." > > so this example should work fine (it wouldn't work if it was char name[1] > though). > Then the original reported code is fine, and the bug is in llvm or llvm-gc (IE Owen is wrong) Note: struct device; struct usb_bus { struct device *controller; }; struct usb_hcd { struct usb_bus self; unsigned long hcd_priv[0]; }; ... > Ciao, > > Duncan. >

...ar (but no so weird) can > > be produced from the attached C source. It is a reduced version of > > preprocessed ehci-hcd.c file (from Linux kernel; compilation of this > > file discovered bug #1782). > > > > --Wojtek > > struct device; > > > > struct usb_bus { > > struct device *controller; > > }; > > > > struct usb_hcd { > > struct usb_bus self; > > > > unsigned long hcd_priv[0]; > > }; > > > > struct ehci_hcd; > > > > static inline __attribute__((always_inline)) struct ehci_hc...

...orld programs. However, something similiar (but no so weird) can > be produced from the attached C source. It is a reduced version of > preprocessed ehci-hcd.c file (from Linux kernel; compilation of this > file discovered bug #1782). > > --Wojtek > struct device; > > struct usb_bus { > struct device *controller; > }; > > struct usb_hcd { > struct usb_bus self; > > unsigned long hcd_priv[0]; > }; > > struct ehci_hcd; > > static inline __attribute__((always_inline)) struct ehci_hcd > *hcd_to_ehci (struct usb_hcd *hcd) > { > ret...

Hi! While investigating into the PR1782 I spent some time analyzing BasicAliasAnalysis.cpp. While the mentioned problem should be fixed now (I hope), I have discovered some other possibilities for a bug to occur. In the case of checking for aliasing of two pointer values, where at least one of them is a GEP instruction with out-of-bound indices, BasicAliasAnalysis can return NoAlias, even if the

...amming technique, for which, after instcombining, a weird GEP is generated. I've pasted fragments of generated assembly code below, if someone is interested. These are the types declared in the code: %struct.device = type opaque ; simplified %struct.ehci_hcd = type opaque ; simplified %struct.usb_bus = type { %struct.device* } %struct.usb_hcd = type { %struct.usb_bus, [0 x i32] } And this is are the interesting instructions. %hcd is a function argument of type %struct.usb_hcd: -= before instcombine =- ; based on some facts it is known the second field of ; structure pointed by %hcd is of ty...

Hi, > Sadly, this will break a very common idiom. In GCC, we discovered it > to be common enough that it broke a *bunch* of C code. > > In particular, you will break > > struct foo { > int a; > char name[0]; > } > > bar = malloc(sizeof (struct foo) + strlen("thisismyname") + 1); > strcpy(bar->name, "thisismyname"); > > > It

Hi, I'm having a hard time configuring a Mustek Powermust 600VA ups to work via USB with nut. I read somewhere that nut works OK via the rs232 cable, but unfortunately I don't have a COM port in my computer. The kernel detects the ups as an Xbox pad :) and loads the xpad module. I tried running /lib/nut/megatec with different /dev/ttySx but it displays megatec protocol UPS was not

Joel Peshkin wrote: > > I hacked in the following additonal changes... > > Index: newhidups.c > =================================================================== > RCS file: /cvsroot/nut/nut/drivers/newhidups.c,v > retrieving revision 1.1.1.1.8.6.2.21 > diff -u -r1.1.1.1.8.6.2.21 newhidups.c > --- newhidups.c 7 Nov 2005 22:14:20 -0000 1.1.1.1.8.6.2.21 > +++

Hi fellows, I'm really pleased to announce that a first stage of NUT and HAL [1] integration has been reached: NUT drivers (in fact, only newhidups, tripplite_usb and bcmxcp_usb for the moment) can feed HAL data. It's a "quick and dirty" hack, as a proof of concept, and there is still lots of things to be done, both on NUT and HAL sides. But it's a good base, and very

Hi Peter, I've forwarded your mail to upsdev as it will be of interest for several people that are working on it. As I'm also on vacation (again) for a week and 1/2 as of this evening, I don't think I'll have the time for it before I get back.... I've not yet audited the patches, but these are queued on the Alioth tracker: