search for: behavior

Hello all, I have a question which I have been struggling with for several weeks now, that I think might be easy for more proficient coders than myself. I have a large behavioral dataset, with behaviors and the times (milliseconds) that they occurred. Each subject has a separate file, and a sample subject file can be generated using the following syntax: Time <- c(1000, 1050, 1100, 1500, 2500, 5000, 6500, 6600, 7000) Behavior <- c("g", "a", &quo...

...wever, I have several files and it becomes tedious to run each one, name it and then aggregate into a single dataframe. Name 0.0           1 21.15       2 2400.26   1 3222.14   2 name = read.table(file.choose(),header=F) # opening a data file colnames(name)<-c("Time", "Behavior") name = data.frame(name$Behavior, name$Time) colnames(name)<-c("Behavior", "Time") name<-name[name$Time < 3600, ]; x<-seq(0,3600, by = 60) # total time partition by time which is 60 if (tail(name$Behavior, 1) == 1) {name<-rbind(name, c(4, 3600))} els...

...ot;Note that in cases where none of the atomic intrinsics are used, this > model places only one restriction on IR transformations on top of what > is required for single-threaded execution: introducing a store to a > byte which might not otherwise be stored to can introduce undefined > behavior.... " > > Why is introducing additional loads allowed? For example, in a program > that already contains two unordered stores to a location l, if we > introduced an unordered load to l, then the load cannot see more than > one stores, it must return undef. The intent of the mod...

Chris Lattner wrote: > On Feb 8, 2009, at 5:54 PM, Paul Schlie wrote: >> Are overflow behavior tags meant to enable the specification of a >> particular instruction's required or presumed overflow behavior? > > I'm not sure what you mean. The overflow tags specify what happens if > overflow happens (defined wrapping, defined saturating, or undefined > behavior), no...

...cases where none of the atomic intrinsics are used, this >> model places only one restriction on IR transformations on top of what >> is required for single-threaded execution: introducing a store to a >> byte which might not otherwise be stored to can introduce undefined >> behavior.... " >> >> Why is introducing additional loads allowed? For example, in a program >> that already contains two unordered stores to a location l, if we >> introduced an unordered load to l, then the load cannot see more than >> one stores, it must return undef. &g...

On 05/30/2013 06:12 AM, Pete Couperus wrote: > Hello, > > This is an interesting example. Whenever I see strange things like > this, I use opt's -lint. > In this case, opt -lint reports: > Undefined behavior: Call return type mismatches callee return type > %call = call float @alias_f32(float %tmp2) #1 > > You'll get a similar report when the parameter types mismatch. > > Pete Is it really supposed to be undefined? The tests are checking for specific behavior in these "undef...

...g a multi-level menu structure seems to require use of >> UP/DOWN/ENTER/ESC. It would be easier to quickly search/navigate if it >> could be done with fingers stationed on the arrow keys so that the eyes >> can stay focused on the screen. >> >> Current (disliked-by-me) behavior: >> LEFT ARROW: Jump to top menu entry (same as HOME and PAGE UP) >> RIGHT ARROW: Jump to bottom menu entry (same as END and PAGE DOWN) > > > A minor correction. In a boot menu, [Home] and [End] move to the > respective first and last items. In a "short" (les...

...re use of >> >> UP/DOWN/ENTER/ESC. It would be easier to quickly search/navigate if it >> >> could be done with fingers stationed on the arrow keys so that the eyes >> >> can stay focused on the screen. >> >> >> >> Current (disliked-by-me) behavior: >> >> LEFT ARROW: Jump to top menu entry (same as HOME and PAGE UP) >> >> RIGHT ARROW: Jump to bottom menu entry (same as END and PAGE DOWN) >> > >> > >> > A minor correction. In a boot menu, [Home] and [End] move to the >> > respec...

Richard, I think adding the runtime undefined behavior checking and unifying the diagnostic output format is a great idea. This would probably be of interest to the LLVM Dev list as well. Anna. On Aug 10, 2012, at 7:48 PM, Richard Smith wrote: > Hi, > > There are three different (and mostly orthogonal, design-wise) areas where I would like...

...cture seems to require use of > >> UP/DOWN/ENTER/ESC. It would be easier to quickly search/navigate if it > >> could be done with fingers stationed on the arrow keys so that the eyes > >> can stay focused on the screen. > >> > >> Current (disliked-by-me) behavior: > >> LEFT ARROW: Jump to top menu entry (same as HOME and PAGE UP) > >> RIGHT ARROW: Jump to bottom menu entry (same as END and PAGE DOWN) > > > > > > A minor correction. In a boot menu, [Home] and [End] move to the > > respective first and last item...

Hi, In our backend, we currently emit add operations that trap on overflow if the IR operation has the nsw flag set. Is this allowed? According to the documentation about poison values, overflowing a nsw add is undefined behavior. However I didn't find a formal definition of undefined behavior in LLVM. Judging from previous discussions on the mailing list, there seems to be a vague line of what LLVM is allowed to do in case of undefined behavior. Is trapping allowed? -Manuel

On 2/28/16, Linus Torvalds <torvalds at linux-foundation.org> wrote: > The fact is, undefined compiler behavior is never a good idea. Not for > serious projects. Actually, undefined behavior is essential for serious projects, but not for the reasons mentioned. If the language has no undefined behavior, then from the compiler's view, there is no such thing as a bad program. All programs will compile...

...4:14 PM, Chris Lattner wrote: >> >> On Dec 16, 2011, at 12:39 PM, Kostya Serebryany wrote: >>> > Do we consider the above transformation legal? >> >> Yes, the transformation is perfectly legal for the normal compiler. > > So how do you guarantee that the behavior is predictable regardless of hardware platform if you don't define what the behavior should be? I'm not sure what you mean. What isn't defined? >>> > I would argue that it should not be legal. We don't actually know what >>> > comes after the 22 byte obje...

I would be interested in learning what the set of used semantics for float-to-int conversion is. If the only two used are 1) undefined behavior if unrepresentable and 2) saturate to int_{min,max} with NaN going to zero, then I think it makes sense to expose both of those natively in the IR. If the set is much larger, I think separate intrinsics for each behavior would make sense. It would be nice to get rid of the wasm-specific intrinsic f...

...-to-implement feature request: Navigating a multi-level menu structure seems to require use of UP/DOWN/ENTER/ESC. It would be easier to quickly search/navigate if it could be done with fingers stationed on the arrow keys so that the eyes can stay focused on the screen. Current (disliked-by-me) behavior: LEFT ARROW: Jump to top menu entry (same as HOME and PAGE UP) RIGHT ARROW: Jump to bottom menu entry (same as END and PAGE DOWN) Preferred (requested) behavior: LEFT ARROW: Return to previous menu (same as ESC on a submenu) RIGHT ARROW: Enter submenu (or no action if not on a submenu...

Are overflow behavior tags meant to enable the specification of a particular instruction's required or presumed overflow behavior? If a required overflow behavior, then it follows that the target must correspondingly implement the behavior; neither natively or emulated? If a presumed overflow behavior, is the targ...

...LVM Atomics and Concurrency >>> Guide states that >>> If code accesses a memory location from multiple threads at the same >>> time, the resulting loads return 'undef'. >>> This is different from the C++ memory model, which provides undefined >>> behavior. What is the rationale for returning an undef on racing >>> reads? >>> >>> LLVM Atomics and Concurrency guide also states the following >>> "Note that speculative loads are allowed; a load which is part of a >>> race returns undef, but does not have...

Hi John, It seems the dereferencing a NULL pointer is undefined behavior but Calling a function through a null pointer seems o.k. If so , for this place, we need comment out the check. http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#232 look at Notes from the October 2003 meeting. Yin From: John Criswell [mailto:criswell at illinois.edu...

...16, 2011, at 12:39 PM, Kostya Serebryany wrote: >>>> >>>> > Do we consider the above transformation legal? >>>> >>> >>> Yes, the transformation is perfectly legal for the normal compiler. >> >> So how do you guarantee that the behavior is predictable regardless >> of hardware platform if you don't define what the behavior should be? > > I'm not sure what you mean. What isn't defined? The alloca in question allocates 22 bytes. The 64-bit load in Kostya's original email is accessing two additional b...

...> Navigating a multi-level menu structure seems to require use of > UP/DOWN/ENTER/ESC. It would be easier to quickly search/navigate if it > could be done with fingers stationed on the arrow keys so that the eyes > can stay focused on the screen. > > Current (disliked-by-me) behavior: > LEFT ARROW: Jump to top menu entry (same as HOME and PAGE UP) > RIGHT ARROW: Jump to bottom menu entry (same as END and PAGE DOWN) A minor correction. In a boot menu, [Home] and [End] move to the respective first and last items. In a "short" (less than one screen) men...