similar to: LLVM.org/viewvc down?

Is there any eta for when viewvc will be back? I prefer to use viewvc because all of the commit emails have the SVN commit number, but not the corresponding git hashes, so it makes it easier to look it up. Or is there some easy way to map an svn commit number to the corresponding git hash? Douglas Yung From: Johan Engelen [mailto:jbc.engelen at gmail.com] Sent: Saturday, March 12, 2016 5:03 AM

It's currently disabled until the issues with llvm.org load would be resolved. Use klaus instead. On Sat, Feb 27, 2016 at 6:53 AM, Yung, Douglas via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Hi, > > > > I’ve noticed since about Thursday that llvm.org/viewvc seems to be only > returning 404 error when trying to access it. Is this service going away? > > >

Unfortunately, we had lot of bogus requests to viewvc (e.g. asking for history / blame for random revision) which looked like a DoS. Most probably we'll enable it after llvm.org will be migrated to new hardware. On Tue, Mar 15, 2016 at 1:24 PM, Hans Wennborg <hans at chromium.org> wrote: > The commit emails, including the ones in the mailing list archives, > also have links to the

Hi, Since ViewVC has been down for a while, I was wondering if it's possible to change the revision links from lab.llvm.org to point elsewhere. For instance, the Phabricator revision if there is one, or maybe the klaus link. Could this be done? Cheers, Diana On Thu, Apr 21, 2016 at 4:32 PM, John Criswell via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On 4/20/16 12:14 PM, Sean

"If memory serves correctly, ViewVC was intentionally disabled because it was causing some problems on the LLVM server (load problems, I think)." If that is the case, perhaps something as simple as a robots.txt will solve the load problem? On Tue, Apr 26, 2016 at 5:26 AM, Hans Wennborg via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I wish we could just get the viewvc

On Mon, Apr 25, 2016 at 1:26 PM, Hans Wennborg via llvm-dev <llvm-dev at lists.llvm.org> wrote: > I wish we could just get the viewvc working or set up some kind of > forwarding from those URLs to something that works. > > There are tons and tons of links pointing to the viewvc which are now > broken, including the archives of all commit emails. I share in that desire; the

Sorry if I was unclear. There are currently no “known incompatibilities” that I am aware of, although I fully admit to not being an expert on the topic. The idea is that we add versioning information to the bitcode so that if an issue were discovered, it could be easily detected and dealt with. Douglas Yung From: Bob Wilson [mailto:bob.wilson at apple.com] Sent: Friday, September 26, 2014 16:39

On Sun, Oct 5, 2014 at 8:10 PM, Yung, Douglas < douglas_yung at playstation.sony.com> wrote: > Hi – > > > > I realize the thread has drifted a little, but I wanted to get back to my > original proposal. I would like to make a change to the bitcode file > wrapper to include the version of llvm that produced the bitcode. I would > like to write this version into the

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 It looks like something, something, something is broken with regards to svn's viewvc linked from the llvm.org front page? Can someone poke an admin about it? http://llvm.org/viewvc/llvm-project/cfe/trunk sean -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJXF6reXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w

On Sat, Sep 27, 2014 at 11:35 PM, Alex Rosenberg <alexr at leftfield.org> wrote: > How is this use case different from the LTO-supported toolchains shipped > by other vendors such as Apple? Do they have this theoretical problem too? > > If the issue is solely constrained to debug info metadata, then why not > use metadata to describe the format/version of the debug info? >

As I understand it, the bitcode compatibility promise doesn't extend as far as debug info metadata (happy to be wrong here!). I think we have a usecase where need to guarantee that debug information from any two arbitrary bitcode files going into an LTO link will result in the expected/correct debug information going into the resulting ELF file; unless we can be sure that this will always

Hi, We would like to add a version number to the bitcode wrapper. This feature would allow easier identification of what compiler produced the bitcode so that known incompatibilities with LTO compilation could be detected. Roughly speaking, this version number would consist of the major, minor and optionally the patch version of the compiler used to produce the bitcode. The version information

Hi Sean, > Rafael gave me some of the backstory on this. Basically it is to work around some buggy behavior in the Darwin ar. Adding that on the front of the bitcode file just to get a version doesn't seem > like a very clean thing to do. > > Doug, what other alternatives did you guys consider before settling on this? > > As for #2 above, the non-universality of the wrapper

Hi, The conversation has drifted slightly, so I wanted to bring it back to the version field in the bitcode wrapper. Currently in the toolchain which we ship and support, we use a proprietary linker. That linker is unable to read bitcode files and we do not have any plans to enable it to as far as I’m aware. Because of this, we need a way of identifying the version of a bitcode file without

I reenabled viewvc with some functionality turned off. Let's see how it will work. On Mon, Apr 25, 2016 at 9:17 PM, Anton Korobeynikov <anton at korobeynikov.info> wrote: > I will try to see whether we could restore limited viewvc functionality. > > On Mon, Apr 25, 2016 at 8:30 PM, Aaron Ballman via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> On Mon, Apr

Hi all, Doug Yung started a discussion earlier ( http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-September/077227.html) about using the unused "version" field in the bitcode wrapper, and I think there was some misunderstanding. I'd like to clarify the motivation. The reason we want to add the version field is to easily identify "old" bitcode. It is only LLVM version

On Mon, Dec 21, 2015 at 12:08 AM, Aaron Ballman <aaron at aaronballman.com> wrote: > On Sun, Dec 20, 2015 at 5:57 PM, Johan Engelen <jbc.engelen at gmail.com> > wrote: > > > > Perhaps LLVM_ATTRIBUTE_ALWAYS_INLINE could be defined to "inline" if the > > compiler has no support for always_inline (currently it is set to > nothing in > > that

Thank you. Guess it's a plausible explanation. > -----Original Message----- > From: Liaw, Andy [mailto:andy_liaw at merck.com] > Sent: Tuesday, December 03, 2002 08:05 AM > To: 'Chunlou Yung' > Subject: RE: [R] Plotting Speed: R vs Octave > > > If I'm not mistaken, Octave does not have its own graphics system, but > rather rely on gnuplot, which is

The fundamental problem is that IR has never been treated as "user input" before. It has always been an ephemeral format, and if some component comes along and sees something it doesn't recognize, that is ipso facto a compiler bug, not a user input error, and it's perfectly okay to crash on a compiler bug. Changing that fundamental assumption would be pretty pervasive. I will

Hi- I am having a weird problem with setting dom0 kernel output to the serial console with Xen 3.0.4-1, below is my grub setting. With this setting if I don''t enter the grub menu and have the default boot to the first image, everything works fine and I can get output/input to the serial console. The problem is when I enter the grub menu and select the image to boot from, if I