So this code uses a locally defined enum in a diagnostic, which results in instantiating a template with a local type as an argument.
Is this a bug in the code or in the compiler? Seems like the code should be fixed to either make the enum global, or explicitly cast it to (int). But I'm not completely sure. AnalysisBasedWarnings.cpp:1126 SemaCast.cpp:772 On Mon, Jun 17, 2013 at 12:38 PM, Renato Golin <[email protected]> wrote: > Hi Evgenly, > > These errors are different than the ones we were seeing in 32-bits. The > latest patch did fix our bots. > > I'm seeing 10 warnings on our bootstrap build, but not that one, which is > weird because it doesn't look like a 64-bit specific part of the code. > > cheers, > --renato > > > On 17 June 2013 09:29, Evgeniy Stepanov <[email protected]> wrote: >> >> Seems like r184053 did not help. >> I see failures on 64-bit bootstrap with -Werror. This is not 32-bit >> specific. >> >> /code/llvm/tools/clang/lib/Sema/SemaCast.cpp:772:48: error: template >> argument uses local type '<anonymous enum at >> /code/llvm/tools/clang/lib/Sema/SemaCast.cpp:710:3>' >> [-Werror,-Wlocal-type-template-args] >> << DerivedType << BaseType << !VirtualBase << ReinterpretKind >> ^~ >> /code/llvm/tools/clang/lib/Sema/AnalysisBasedWarnings.cpp:1126:7: >> error: template argument uses local type '<anonymous enum at >> /code/llvm/tools/clang/lib/Sema/AnalysisBasedWarnings.cpp:1105:5>' >> [-Werror,-Wlocal-type-template-args] >> << ObjectKind << D << FunctionKind >> ^~ >> /code/llvm/tools/clang/lib/Sema/AnalysisBasedWarnings.cpp:1126:26: >> error: template argument uses local type '<anonymous enum at >> /code/llvm/tools/clang/lib/Sema/AnalysisBasedWarnings.cpp:1067:3>' >> [-Werror,-Wlocal-type-template-args] >> << ObjectKind << D << FunctionKind >> ^~ >> >> On Sun, Jun 16, 2013 at 7:02 PM, Larisse Voufo <[email protected]> wrote: >> > >> > >> > >> > On Sun, Jun 16, 2013 at 6:13 AM, Renato Golin <[email protected]> >> > wrote: >> >> >> >> On 16 June 2013 14:10, Renato Golin <[email protected]> wrote: >> >>> >> >>> Random failures occur, but they tend to be compilation errors, for >> >>> instance for lack of memory or timeout. Sometimes, MCJIT tests fail >> >>> randomly, and we're trying to get those fixed as well. So, if the >> >>> compiler >> >>> error is something like "unrecoverable error" with no error message, >> >>> it's >> >>> probably not your fault. If the error is in a test that has nothing to >> >>> do >> >>> with your change (ex. MCJIT failures after a C++11 change), it should >> >>> be >> >>> safe to ignore, too. But we appreciate >> >> >> >> >> >> Sorry, CTRL+ENTER sends the email on GMail and I hit it while trying >> >> CTRL+BACKSPC. Continuing... >> >> >> >> We appreciate if you could always have a look at the breaking bots when >> >> you receive an email from the buildmaster, as you could fix the bug >> >> while >> >> the maintainers are sleeping... ;) >> > >> > >> > Roger. Thanks for the info. I think the r184053 push fix some of these. >> > I'm >> > verifying my tests execution in 32-bit mode. >> > >> >> >> >> >> >> cheers, >> >> --renato >> > >> > >> > >> > _______________________________________________ >> > cfe-commits mailing list >> > [email protected] >> > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits >> > > > _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
