search for: gcc_assert

...e builds, often leading to compiler warnings when the compiler thinks a control path doesn't return a value. if the point is to have a better assert, why not introduce llvm_assert and do a bulk replace of all asserts with it? By the way, GCC does this: #ifdef ENABLE_RUNTIME_CHECKING #define gcc_assert(EXPR) ((void)(!(EXPR) ? abort (), 0 : 0)) #else /* Include EXPR, so that unused variable warnings do not occur. */ #define gcc_assert(EXPR) ((void)(0 && (EXPR))) #endif /* Use gcc_unreachable() to mark unreachable locations (like an unreachable default case of a switch. Do not use gcc...

On 12.03.2011, at 11:17, Duncan Sands wrote: > Hi John, > >> This patch implements the current consensus of PR8973: >> http://llvm.org/bugs/show_bug.cgi?id=8973. >> >> The macro llvm_unreachable is used in LLVM to indicate that >> a particular place in a function is not supposed to be reachable >> during execution. Like an assert macro, it takes a

...cc/dwarf2out.c 2008-07-30 20:58:16.000000000 +0200 @@ -11480,9 +11480,8 @@ dw_die_ref type_die = NULL; /* APPLE LOCAL begin radar 5811943 - Fix type of pointers to blocks */ - if (code == BLOCK_POINTER_TYPE) + if (code == BLOCK_POINTER_TYPE && invoke_impl_ptr_type) { - gcc_assert (invoke_impl_ptr_type); type = invoke_impl_ptr_type; code = TREE_CODE (type); } Index: gcc-4.2.llvm/gcc/tree.h =================================================================== --- gcc-4.2.llvm.orig/gcc/tree.h 2008-07-30 21:01:15.000000000 +0200 +++ gcc-4.2.llvm/gcc/tree.h 2008...

...ava) still do. I had a look at the GO front-end and I see this suspicious code: /* This is called by the Go frontend proper to add data to the .go_export section. */ void go_write_export_data (const char *bytes, unsigned int size) { static section* sec; if (sec == NULL) { gcc_assert (targetm_common.have_named_sections); sec = get_section (".go_export", SECTION_DEBUG, NULL); } switch_to_section (sec); assemble_string (bytes, size); } So you might want to check if copying .go_export sections from the GCC compiled assembler file into the dragonegg co...

The curent llvm svn (r54623) is unable to link the gfortran compiler in llvm-gcc-4.2 svn. I am getting the error... c++ -g -O2 -mdynamic-no-pic -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute -mdynamic-no-pic -DHAVE_CONFIG_H -o f951 \

Hi! I've been working on coroutines for some time, and it seems you were right - it makes much more sense to have regular C (and assembly) code for handling coroutines. For instance, I'd otherwise would have to make an assumption about the threading model the platform has (or assume there are no threads at all, which prevents me from allowing goroutine like ("run parallel till you

On Jul 30, 2008, at 11:39 AM, Duncan Sands wrote: > On Wednesday 30 July 2008 18:13:27 Duncan Sands wrote: >> On x86-64 linux, in stage 2, I get: >> >> c++ -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict- >> prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno- >> variadic-macros -Wno-overlength-strings -Wold-style-definition - >>

...l_functions (construct_reverse_callgraph, root); propagate_chains (root); #endif ... } The construct_reverse_callgraph calls lookup_context_for_decl, where it crashes: lookup_context_for_decl (tree fndecl) { ... slot = (struct nesting_info **) htab_find_slot (ni_map, &dummy, NO_INSERT); gcc_assert (slot != NULL); /* CRASHES HERE */ return *slot; } construct_reverse_callgraph (tree *tp, int *walk_subtrees, void *data) { ... switch (TREE_CODE (t)) { case ADDR_EXPR: ... /* Add an edge from the callee to the caller. */ pointer_set_insert (lookup_context_for_decl (decl)...

...his suspicious code: > > /* This is called by the Go frontend proper to add data to the > .go_export section. */ > > void > go_write_export_data (const char *bytes, unsigned int size) > { > static section* sec; > > if (sec == NULL) > { > gcc_assert (targetm_common.have_named_sections); > sec = get_section (".go_export", SECTION_DEBUG, NULL); > } > > switch_to_section (sec); > assemble_string (bytes, size); > } :-( Fixing things like this was fairly painful in the past. It is sad to see new case...

>> >> If any ARM/GCC experts know how to fix arm.md to not refer to >> Darwin-specific macros, that would be great, too. > > Probably the right general idea is to #define MACHO_DYNAMIC_NO_PIC_P > to be 0 for non-Darwin targets. Not sure where to put this so it > will work for both targets (the Darwin definition comes from config/ > darwin.h). I don't

On Mar 12, 2009, at 8:30 AMPDT, Misha Brukman wrote: > > ../../../../src/llvm-gcc4.2-2.5.source/gcc/config/arm/arm.md:4788: > error: ‘MACHO_DYNAMIC_NO_PIC_P’ undeclared here (not in a function) > > This tells me there are some Darwin-specific bits in arm.md which > shouldn't be there (MachO is Mac OS X-specific). I'm using the > attached script

...ing the prerelease of llvm-gcc 2.4 on Intel darwin9 with the following patch... --- llvm-gcc-4.2-2.3.999-20081024.source/gcc/stub-c.c.org 2008-10-30 18:55:45.000000000 -0400 +++ llvm-gcc-4.2-2.3.999-20081024.source/gcc/stub-c.c 2008-10-30 18:57:29.000000000 -0400 @@ -157,3 +157,27 @@ { gcc_assert(0); } + + +bool cvt_utf8_utf16 (const unsigned char *, size_t, unsigned char **, + size_t *) ATTRIBUTE_WEAK; + +bool +cvt_utf8_utf16 (const unsigned char * inbuf ATTRIBUTE_UNUSED, + size_t length ATTRIBUTE_UNUSED, + unsigned char ** uniCharBuf ATT...