On 18 April 2016 at 08:39, lh_mouse wrote:
> I have added a thread model and added its corresponding header files. But it
> failed the linker.
>
> The file 'gcc/libgcc/config/i386/t-mingw-pthread' which contained two lines:
> SHLIB_PTHREAD_CFLAG = -pthread
> SHLIB_PTHREAD_LDFLAG = -Wl,-lpthrea
On 18 April 2016 at 10:18, lh_mouse wrote:
>> I don't see why it has to be a struct, it just has to be suitable as
>> an argument to the relevant __gthread functions.
>
> The type __gthread_time_t is referenced in
> gcc/libstdc++-v3/include/std/mutex:157
> __gthread_time_t __ts = {
>
On 18 April 2016 at 10:57, Jonathan Wakely wrote:
> On 18 April 2016 at 10:18, lh_mouse wrote:
>>> I don't see why it has to be a struct, it just has to be suitable as
>>> an argument to the relevant __gthread functions.
>>
>> The type __gthread_time_t is refe
On 20 April 2016 at 18:31, lh_mouse wrote:
> I tend to say clang is wrong here.
If you can't detect the difference then it is a valid transformation.
> Your identifier 'a' has no linkage. Your object designated by 'a' does not
> have a storage-class specifier.
> So it has automatic storage durat
On 21 April 2016 at 03:41, lh_mouse wrote:
> See this example: http://coliru.stacked-crooked.com/a/048b4aa5046da11b
>
> In this example the function is called recursively.
See the original email you replied to:
"I understand if this function is recursive and pointer of the array
is involved, GCC
This is the wrong mailing list for such questions, the gcc-help list
would be appropriate.
On 21 April 2016 at 02:11, Zan Lynx wrote:
> I would like someone to look at this and tell me this is an already
> fixed bug. Or that recent GCC patches may have fixed it. :-)
>
> Or it would also be great
On 21 April 2016 at 12:11, Szabolcs Nagy wrote:
> the root cause is c++: c++ headers include random libc headers with
> _GNU_SOURCE ftm so all sorts of unexpected symbols are defined/declared.
Yes, I'd really like to be able to stop defining _GNU_SOURCE
unconditionally. It needs some libstdc++ and
On 21 April 2016 at 13:33, Szabolcs Nagy wrote:
> On 21/04/16 12:52, Jonathan Wakely wrote:
>> On 21 April 2016 at 12:11, Szabolcs Nagy wrote:
>>> the root cause is c++: c++ headers include random libc headers with
>>> _GNU_SOURCE ftm so all sorts of unexpected s
On 21 April 2016 at 15:32, Joel Sherrill wrote:
>> Those rules belong in a POSIX binding for C++, not in the C++
>> standard, but unfortunately the group working on that has been
>> inactive for some time.
>>
>> (In the absence of an official binding, I think a reasonable rule that
>> would work fo
On 21 April 2016 at 17:47, Jason Merrill wrote:
> On Thu, Apr 21, 2016 at 11:57 AM, Jonathan Wakely
> wrote:
>>
>> I once tried to write a gcc plugin that would check all names defined
>> by libstdc++ and ensure they were either in the reserved namespace, or
>>
On 2 May 2016 at 11:41, lh_mouse wrote:
> However, I am not exactly clear about whether it is these headers (cstdlib
> and cmath currently, there might be more) that are the problem.
No, it's only those two.
> In my point of view, it is the inversion of C and C++ header paths that is
> the prob
On 8 May 2016 at 02:10, Christopher Di Bella wrote:
> Hi all,
>
> I've been tracking gcc-digest for a bit, but would like to be a little
> more involved in the development of gcc.
>
> I haven't been able to find anything about the CppCoreGuidelines in
> gcc -- I'm wondering if there's a warning sys
On 17 May 2016 at 12:10, Christopher Di Bella wrote:
>> I don't know the status of the static analysis tool the Microsoft were
>> planning to release, which would do a lot of the checking.
>
> As far as I'm aware, this is a Visual Studio tool, and thus closed
> source. I might be wrong!
Currently
On 23 June 2016 at 01:10, Soul Studios wrote:
> Hi there-
> quick question,
It would have been better on the libstdc++ mailing list.
> does deque as defined in libstdc++ allocate upon initialisation or upon
> first insertion?
Unfortunately our std::deque allocates some memory in its default
cons
On 22 June 2016 at 10:28, David Wohlferd wrote:
> And I *get* that it takes time to re-write this, and people have schedules,
> lives, a need for sleep. But even under the most insanely aggressive
> schedule I can imagine (if gcc continue to release ~1/year), it will be at
> least a year before th
On 10 July 2016 at 15:18, Yubin Ruan wrote:
> Hi,
> I am reading some OS kernel codes, and I find that in the Makefile used
> to build the kernel, there is a **-fno-pic** flag. I totally don't
> understand what that mean. I try to find some description from the man pages
> but can find no direc
On 15 July 2016 at 00:45, Patrick Oppenlander wrote:
> Hi,
>
> I'm running into a build problem when building GCC 6.1.0:
>
>
> /home/patrick/src/e7/toolchain/build/gcc-6.1.0-stage2/./gcc/xgcc
> -shared-libgcc -B/home/patrick/src/e7/toolchain/build/gcc-6.1.0-stage2/./gcc
> -nostdinc++
> -L/home/patr
On 26 July 2016 at 14:31, Warren D Smith wrote:
> 1. Gcc with stdint.h already
> provides such nice predefined types as uint8_t.
> Sizes provided are 8,16,32, and 64.
> In some sense uint1_t is available too (stdbool.h)
> but at least on my machine stdbool uses 8-bits to store a bool,
Because that
I propose that we remove the following non-standard traits in GCC 7:
/// has_trivial_default_constructor (temporary legacy)
template
struct has_trivial_default_constructor
: public integral_constant
{ } _GLIBCXX_DEPRECATED;
/// has_trivial_copy_constructor (temporary legacy)
templat
Let's imagine we have a 4-bit type, called nibble.
sizeof(nibble) == 1, because you can't have an object with a smaller size.
nibble a[2];
sizeof(a) == 1;
Because otherwise there isn't much benefit.
So now we have a type which violates one of the core rules of the type
system. sizeof(nibble[2 *
On 29 July 2016 at 20:01, Warren D Smith wrote:
>> Given a pointer to an array of nibbles and a length, how do I iterate
>> through the array?
>
> for(i=0; i
> --correction, that was for an array of packed bools. For nybbles,
> bitsizeof(a)/4. There are various games one can play, and quibbles one
On 31 July 2016 at 07:08, phi gcc wrote:
> Hi All,
>
> Reposting this here from gcc-help.
>
>
> I got the impression that I got colors in diag output depsite the fact
> that I got no GCC env var setup.
The manual says "Setting GCC_COLORS to the empty string disables colors."
Did you try that? Set
On 31 July 2016 at 22:06, phi gcc wrote:
> bugzilla don't likes me, can't get in
> Ok let's forget participation then...
We were attacked by spammers last week and had to temporarily disable
account creation. The notice you got from bugzilla should have given
the details of an admin to contact
On 4 August 2016 at 21:12, Manuel López-Ibáñez wrote:
> d) Delegate hierarchically. Module owners should seek and delegate to people
> with svn-write powers and ask for reviews in exchange of reviews.
>
> Advantages: No loss in quality, distribute work, creates an economy of
> reviews.
>
> Disadvan
On 5 August 2016 at 19:26, Manuel López-Ibáñez wrote:
> I'd be happy to see my hypothesis disproved.
Does it matter?
There are lots of people contributing a few patches, and there are
also a few people contributing lots of patches. Trying to prove or
disprove a hypothesis about the health of the
On 18 August 2016 at 08:59, Richard Biener wrote:
> No, but you can try --enable-version-specific-runtime-libs
But be aware that for multilib targets that's been broken for years, PR32415
On 19 August 2016 at 07:29, David Wohlferd wrote:
> Interesting. Seems slightly strange, but I've seen stranger. I guess it's
> seen as "cleaner" than forcing this into 2 statements.
That's not the reason for the C++ rule. It's that you don't
necessarily know what the return type is, e.g.
templ
I'm confused by what I'm seeing when running the libstdc++ tests with:
RUNTESTFLAGS='--target_board=\"unix{-std=gnu++98,-std=gnu++11,-std=gnu++14,-std=gnu++17}\"'
If I inspect the libstdc++.sum file to look for the results for a
particular file that has { dg-do compile { target c++14 } }, I find
On 22/08/16 21:16 +0100, Pedro Alves wrote:
On 08/22/2016 03:40 PM, Jonathan Wakely wrote:
What's going on?!
Have I fundamentally misunderstood something about how RUNTESTFLAGS or
effective-target keywords work?
Here's a wild guess.
In gdb's testsuite, I've seen odd
On 23/08/16 09:07 +0100, Jonathan Wakely wrote:
On 22/08/16 21:16 +0100, Pedro Alves wrote:
On 08/22/2016 03:40 PM, Jonathan Wakely wrote:
What's going on?!
Have I fundamentally misunderstood something about how RUNTESTFLAGS or
effective-target keywords work?
Here's a wild
On 11 September 2016 at 22:38, Paul Smith wrote:
> I wonder if someone can comment on this situation: I'll do some testing
> but I likely can't test everything.
>
> I'm creating DSO's for GNU/Linux with GCC 4.9.2 right now. I want to
> upgrade to GCC 6.2.0. My code is written in C++. I'm aware o
On 14 September 2016 at 15:26, Paul Smith wrote:
> On Wed, 2016-09-14 at 10:13 +0100, Jonathan Wakely wrote:
>> The real problem is that your library will depend on a newer libstdc++
>> but that's orthogonal to the ABI changes. Statically linking it is one
>> solution, d
any clear report of
someone using it I understand that it is preferable to get rid of it.
François
On 17/09/2016 00:17, Jonathan Wakely wrote:
Libstdc++ features a "Profile Mode", see
https://gcc.gnu.org/onlinedocs/libstdc++/manual/profile_mode.html
We've been carrying thousands o
On 4 October 2016 at 10:21, David Brown wrote:
> On 04/10/16 01:48, Martin Sebor wrote:
>> In a recent review Jason and I discussed the style convention
>> commonly followed in the C++ front end to annotate arguments
>> in calls to functions taking bool parameters with a comment
>> along the lines
On 4 October 2016 at 12:39, Bernd Schmidt wrote:
> On 10/04/2016 12:41 PM, Jonathan Wakely wrote:
>>
>> On 4 October 2016 at 10:21, David Brown wrote:
>>>
>>> On 04/10/16 01:48, Martin Sebor wrote:
>>>>
>>>> In a recent review Jason and I
On 4 October 2016 at 12:55, David Brown wrote:
> On 04/10/16 12:41, Jonathan Wakely wrote:
>> On 4 October 2016 at 10:21, David Brown wrote:
>>> On 04/10/16 01:48, Martin Sebor wrote:
>>>> In a recent review Jason and I discussed the style convention
>>>>
On 4 October 2016 at 16:41, wrote:
>
>> On Oct 3, 2016, at 7:48 PM, Martin Sebor wrote:
>>
>> In a recent review Jason and I discussed the style convention
>> commonly followed in the C++ front end to annotate arguments
>> in calls to functions taking bool parameters with a comment
>> along the
On 4 October 2016 at 16:51, wrote:
>
>> On Oct 4, 2016, at 11:46 AM, Jonathan Wakely wrote:
>>
>> On 4 October 2016 at 16:41, wrote:
>>>
>>>> On Oct 3, 2016, at 7:48 PM, Martin Sebor wrote:
>>>>
>>>> In a recent review Jason
On 7 October 2016 at 21:41, nicolas bouillot wrote:
> oops this works better:
> alias reversed_make='make 2>&1 >/dev/null | tac | egrep --color
> "\b(error|cpp|hpp)\b|$"'
Or just make 2>&1 | less
On 7 October 2016 at 22:26, Joseph Myers wrote:
> On Fri, 7 Oct 2016, Frank Ch. Eigler wrote:
>> FWIW, I thought at one point the consensus was that the mailmap would
>> expand only to $use...@gcc.gnu.org rather than $userid@$organization,
>> esp. considering the case where there is no single $orga
On 20 October 2016 at 16:13, Bernhard Schommer wrote:
> Hi,
>
> for local version of different gcc version (c/c++ - only) we want to
> minimize the size of the sources in our local git. What can be removed
> without problems?
What kind of problems? Do you care about optional things like the
saniti
On 19 October 2016 at 18:45, Ellcey, Steve wrote:
> I have built the latest glibc sources with a ToT GCC and am trying to run the
> glibc testsuite now. I ran into a couple of
> new warnings that I fixed (locally) and am now looking at
> nptl/tst-thread_local1.cc which dies with:
>
> tst-thread_
On 17 November 2016 at 03:58, lhmouse wrote:
> If a program is compiled with `-fno-exceptions` and an exception
> will have been thrown otherwise, `std::abort()` (or an equivalent such as
> `__builtin_trap()`) is called. This preserves the semantical correctness
> of not checking the value of a thr
N.B. This has already been answered on gcc-help, where it belongs.
Sorry for not updating this list to say so.
I've also now added this topic to the isocpp.org FAQ:
https://isocpp.org/wiki/faq/templates#dependent-name-lookup-types
On 2 December 2016 at 12:12, chenzero wrote:
> Hello,
>
> I have f
On 8 December 2016 at 22:05, Ethin Probst wrote:
> As I do not know how to fix these other than to resolve them, I have
> done so,
You haven't resolved anything, all you've done is *tell* svn that you
resolved them, without actually doing so. The files still have
conflicts in, and all you've done
On 10 December 2016 at 03:21, Andrew Pinski wrote:
> What version of GCC? Is this trunk? If so java was removed a few months ago.
We need to document that at https://gcc.gnu.org/gcc-7/changes.html
On 10 December 2016 at 13:52, Prathamesh Kulkarni wrote:
> I wonder though how I didn't see these failures. Is compile the default ?
Yes, { dg-do compile } is the default.
That can be changed by .exp files, which is done by
libstdc++-v3/testsuite to make { dg-do run } the default.
On 14 December 2016 at 11:21, Janus Weil wrote:
> Do we already have a gcc.css, and if yes where?
https://gcc.gnu.org/gcc.css
On 16 December 2016 at 06:46, Sandra Loosemore wrote:
> Looking at the structure of the whole manual, though, I see that most of it
> is in fact a tutorial on how to use the preprocessor language, like you
> would find in a C programming book. Is this a useful thing for us to be
> providing? Offh
Instead of replacing the global new operator we could write a custom
allocator that uses xmalloc, and we can have e.g. gcc::string as a
typedef for std::basic_string,
gcc::xmallocator>
On 17 December 2016 at 12:28, Pedro Alves wrote:
> On 12/17/2016 12:23 PM, Jonathan Wakely wrote:
>> Instead of replacing the global new operator we could write a custom
>> allocator that uses xmalloc, and we can have e.g. gcc::string as a
>> typedef for std::basic_string
On 19 December 2016 at 10:17, Seima Rao wrote:
> I was referring to one of three approaches:
>
> i) Write a Specification document and a matching testsuite
>
> ii) Document _all_ data and code together with file formats
>(e.g. dumps).
>
> iii) Both (i) & (ii)
>
> (i) is easy
I disagree.
A fun
On 23 April 2014 10:33, Rainer Emrich wrote:
>
> The requested URL /onlinedocs/gcc-4.9.0/libstdc++-api.pdf.gz was not found on
> this server.
Yes, onlinedocs/gcc-4.9.0/libstdc++-api-gfdl.xml.gz is also missing, I
didn't figure out how to generate them yet!
On 25 April 2014 11:22, Andrew Haley wrote:
> Summary: Devirtualization uses type information to determine if a
> virtual method is reachable from a call site. If type information
> indicates that it is not, devirt marks the site as unreachable. I
> think this is wrong, and it breaks some program
On 25 April 2014 13:01, Richard Biener wrote:
> On Fri, Apr 25, 2014 at 1:18 PM, Jonathan Wakely
> wrote:
>> On 25 April 2014 11:22, Andrew Haley wrote:
>>> Summary: Devirtualization uses type information to determine if a
>>> virtual method is reachable from a c
On 29 April 2014 16:25, Yaron Dayagi wrote:
> Hello,
> In gcc 4.4.6 we had no problem with the order of initialization.
> In gcc 4.7.2 we do have a problem.
> A CPP file defined GlobalObj_1 (declared extern in the H file):
> CMyClass GlobalObj_1.
> Another CPP file declared GlobalObj_2 (also declar
On 1 May 2014 22:17, Joel Sherrill wrote:
> This seems to fix it. I am not sure why sh.c is the only file in
> gcc/config which includes sstream though. Is this a violation
> of some new rule?
A rule that a feature can only be used if it's in more than one file? ;-)
> Is there a PR for this?
ht
On 20 May 2014 11:26, Bruce Adams wrote:
>
> RHEL4 (kernel 2.6.9-55.ELsmp):
>
>
> I was able to compile 4.8.1 successfully when it was released. 4.9.0 fails as
> below.
> RHEL4 is end of life (but not extended life).
>
> My feeling is this ought to work and is probably a regression I should report
On 20 May 2014 11:55, Eric Botcazou wrote:
>> [snip]
>> /development/dev1/brucea/gcc4.7/bin/../lib/gcc/i686-pc-linux-gnu/4.7.0/../..
>> /../../i686-pc-linux-gnu/bin/ld: /home/brucea/gcc4 .9/lib/libmpfr.so:
>> undefined reference to symbol '___tls_get_addr@@GLIBC_2.3'
>> /development/dev1/brucea/gcc
> If I search for "ALL cilk 4.9" or "ALL cilk" it is still not obvious that the
> cilk branch
> was merged into main prior to release 4.9.0. Though that could be down to my
> unfamiliarity with more complex queries in bugzilla.
Our bugzilla is usually used for tracking bugs, not merging of featu
On 22 May 2014 16:12, Kenny Simpson wrote:
> PR60901 is listed in the bug fixes for gcc 4.8.3, but I don't see the patch
> ever applied to the 4_8 branch in the bug report,
The PR shouldn't have been closed without either changing the Target
Milestone or backporting the patch to the release branc
On 2 June 2014 12:38, Carlos Sánchez de La Lama wrote:
> If V9 is indeed required, is there a way to build without those libs? Or
> has pre V9 support been dropped at some point?
--disable-libitm --disable-libatomic
On 2 June 2014 16:45, Michael Meissner wrote:
> I have not been following the language standards recently. For any of the
> recent language standards, or the standards that are being worked on, will
> there be requirements for an IEEE 128-bit binary floating point type?
The recent http://www.open
On 3 June 2014 01:47, Vincent Lefevre wrote:
> On 2014-06-02 10:33:37 -0400, Geert Bosch wrote:
>> It should, or it would be a bug. Please feel free to add/correct
>> anything on this page.
>
> I am not a member of EditorGroup.
That's easy to fix, email me your username.
On 10 June 2014 15:00, Basile Starynkevitch wrote:
> Once all is done and signed (both by FSF and you or your employer), add your
> real name in MAINTAINERS file.
That's not needed until you get write access to the repository, but
you can submit patches and contribute without write access.
On 10 June 2014 16:38, Jonathan Wakely wrote:
> On 10 June 2014 15:00, Basile Starynkevitch wrote:
>> Once all is done and signed (both by FSF and you or your employer), add your
>> real name in MAINTAINERS file.
>
> That's not needed until you get write access to the
On 10 June 2014 17:20, Hebenstreit, Michael wrote:
> Either something is broken on my web-access or the links on
> https://gcc.gnu.org/install/prerequisites.html pointing to
> ftp://gcc.gnu.org/pub/gcc/infrastructure/ are gone - can't find the files
> anywhere else :(
The FTP site and files are
On 10 June 2014 17:41, Jonathan Wakely wrote:
> On 10 June 2014 17:20, Hebenstreit, Michael wrote:
>> Either something is broken on my web-access or the links on
>> https://gcc.gnu.org/install/prerequisites.html pointing to
>> ftp://gcc.gnu.org/pub/gcc/infrastructure/ are
On 12 June 2014 10:40, Florian Weimer wrote:
> In GCC 4.9, we have optimizations that make use of non-null annotations, at
> least for removing null pointer checks. Some libc functions are annotated
> with it, such as qsort, memcpy, memset, memcmp.
Yep, as described at https://gcc.gnu.org/gcc-4.9
I just realised that all our source files still say -2013 on the
4.8 branch, because the branch was created last year and the script to
update all the files in January only gets run on trunk.
Is that a problem, or is it OK for files on the branches to only have
copyright dates up to the point
On 13 June 2014 22:29, Joel Sherrill wrote:
> Hi
>
> I am trying to build a native GNAT from the head on Fedora 20. It has
> makeinfo 5.1 which is causing gnat_rm.texi a lot of problems. This
> is just the beginning of almost 200 error messages.
>
> ../../gcc/gcc/ada/gnat_rm.texi:4107: warning: @it
On 1 July 2014 09:40, Matthias Klose wrote:
> - HPPA (build log [2]), is missing all the future_base symbols and
>exception_ptr13exception symbols, current_exception and
>rethrow_exception.
This implies ATOMIC_INT_LOCK_FREE <= 1 for that target. Our future and
exception_ptr implementation
On 1 July 2014 20:58, John David Anglin wrote:
> On 1-Jul-14, at 5:32 AM, Jonathan Wakely wrote:
>
>> On 1 July 2014 09:40, Matthias Klose wrote:
>>>
>>> - HPPA (build log [2]), is missing all the future_base symbols and
>>> exception_ptr13e
On 7 July 2014 12:08, Tobias Grosser wrote:
>
> The number of elements in these maps is most likely between 3-10.
Then std::map is the wrong solution.
The overhead of dereferencing all the pointers while walking through a
std::map will be higher than the savings you get from logarithmic
lookup.
On 29 July 2014 21:58, Eric Botcazou wrote:
>> How does it change meaning? It's still the major number, just
>> incremented more often.
>
> Reread Ian's post, the original idea is to drop the major version number.
I think you're confusing the topic now.
What are you objecting to, calling the nex
On 30 July 2014 23:18, Eric Botcazou wrote:
>> What are you objecting to, calling the next release from trunk 5.0,
>> and the next one after that 6.0? Or the wording chosen to describe the
>> new versioning scheme?
>
> Let's not start another subthread, please, this will be even more confusing.
I'
On 6 August 2014 10:06, Jakub Jelinek wrote:
> On Wed, Aug 06, 2014 at 11:04:14AM +0200, Richard Biener wrote:
>> > - libstdc++ ABI changes (it is a significant user visible change,
>> > if you rebuild everything, no extra effort is needed, but otherwise
>> > if you want some C++ code built wit
On 6 August 2014 11:20, Richard Biener wrote:
> On Wed, Aug 6, 2014 at 12:08 PM, Jonathan Wakely
> wrote:
>> On 6 August 2014 10:06, Jakub Jelinek wrote:
>>> On Wed, Aug 06, 2014 at 11:04:14AM +0200, Richard Biener wrote:
>>>> > - libstdc++ ABI changes (it
On 5 August 2014 19:32, Роман Донченко wrote:
> Hello,
>
> Tags for the following releases are not in the Git mirror repository:
>
> * 3.3
> * 3.3.1
> * 3.3.5
> * 3.3.6
> * 4.7.4
> * 4.8.3
> * 4.9.1
>
> I figure this is the place to report it?
Yes, this is the right place, thanks. The tags in th
On 6 August 2014 20:12, wrote:
> But the preferred answer in my mind is to get rid of this thing and go back
> to displaying the whole page. If you do want to keep the subset thing, at
> least make it NOT the default.
IIRC that causes timeouts when the site is busy, because it has to
fetch a
On 7 August 2014 06:33, Joshua Kinardwrote:
> For my own information, what's the cutoff date for fixes to regressions like
> this to make it into gcc-4.9.1?
A month ago, https://gcc.gnu.org/ml/gcc/2014-07/msg00103.html
The GCC home page has links to the status report emails for each active branch.
On 05/09/14 13:05 +0200, Thomas Schwinge wrote:
Updating my GCC trunk working tree from r212389 (2014-07-09) to r214918
(2014-09-04), I notice that (only) in libstdc++ testing, and only for the
second multilib of »RUNTESTFLAGS='--target_board=unix\{,-m32\}'« (so, the
32-bit x86 one), a lot of PAS
On 8 September 2014 11:53, Swati Rathi wrote:
>
> How to identify object of a class which is defined in the library file?
>
> For e.g.
> struct basic_ostream & D.2782;
>
>
> Variable D.2782 is object of class which is part of the library file.
> How can we identify such a variable?
Repeating the
On 11 September 2014 07:22, VandeVondele Joost wrote:
> Jakub,
>
>> First of all, the -j2 testing shows more tests tested in gcc and libstdc++:
>>
>>-# of expected passes 10133
>>+# of expected passes 10152
>>
>>+PASS: 23_containers/set/modifiers/erase/abi_tag.cc (test for exce
On 11 September 2014 15:45, VandeVondele Joost
wrote:
>
>>> could it be that the pattern in normal1 should have been '[ab]*/ de*/
>>> [ep]*/*' ?
>>
>>Yes, we are running these tests multiple times:
>>
>>PASS: 23_containers/map/modifiers/erase/abi_tag.cc (test for excess errors)
>>PASS: 23_contai
On 12/09/14 09:47 +, VandeVondele Joost wrote:
a newer patch (v8) I'll send soon
attached with updated changelog. Compared to the previously posted v6, only the
libstdc++-v3/testsuite/Makefile.am has been refined to split a little more the
e*/* pattern, and two quickly running goal have
On 14 September 2014 20:03, Andreas Schwab wrote:
> Frédéric Buclin writes:
>
>> Could one of you give me a short and clear description of each of the
>> Host, Target and Build fields used in GCC Bugzilla?
>
> It's the same as what you pass to configure as --build, --host, --target.
i.e. Build i
On 18 September 2014 23:46, Ian Grant wrote:
> On Thu, Sep 18, 2014 at 5:22 PM, Tobias Ulmer wrote:
>> On Wed, Sep 17, 2014 at 01:26:48PM -0400, Ian Grant wrote:
>>> I can compile the first stage OK, and the binaries are quite modest:
>>>
>>> -rwxr-xr-x 1 ian ian 17.2M Sep 6 03:47 prev-gcc/cc1
On 19 September 2014 00:07, Ian Grant wrote:
>
> Actually, when I look at the output of size I realise I don't know
> what it means:
>
> ian3@jaguar:~/usr/libexec/gcc$ size i686-pc-linux-gnu/4.9.0/{cc1,f951}
>text databssdechexfilename
> 14965183 23708
On 19 September 2014 16:21, Ian Grant wrote:
> Thanks. But I asked what the non-vanilla sources were. I know what
> the vanilla sources are, because I'm using them!
The non-vanilla sources are everything else. That should be pretty obvious.
Are you just intentionally trying to waste everyone's t
On 20 September 2014 00:01, Jonathan Wakely wrote:
> On 19 September 2014 16:21, Ian Grant wrote:
>> Thanks. But I asked what the non-vanilla sources were. I know what
>> the vanilla sources are, because I'm using them!
>
> The non-vanilla sources are everything e
On 20 September 2014 00:52, Ian Grant wrote:
> None of this is useful to me. I'm trying to make a case for why people
> should have confidence in GNU software. You are NOT helping me in
> that, I assure you,
You seem to have already made up your mind it's GNU crap.
Being insulting is a funny way
we export the symbols at GLIBCXX_3.4
unconditionally. Applying the patch now would alter the symbol version
for the wstringbuf::str() symbol.
Maybe we should just remove the duplicates in the later symbol version
sections, but I'm not confident enough to do it!
commit bd23198d87a6c04ea554102
On 24 September 2014 22:49, George R Goffe wrote:
> Hi,
>
> I'm having trouble building the latest gcc on my fedora 19 x86_64 system.
This mailing list is for discussing development of gcc itself, please
use the gcc-help list for help building or using gcc.
Please send your question there instead
On 27 September 2014 22:13, George R Goffe wrote:
> Hi,
>
> I'm having trouble getting email to Christoph who manages(?) the gcc-bugs
> mailing list. My emails are rejected. I'm not an email guy so the messages
> are rather indecipherable to me. Below is what I'm seeing.
>
> Regards,
>
> George..
On 30 September 2014 01:25, wrote:
>
> On Sep 29, 2014, at 7:59 PM, George R Goffe wrote:
>
>>
>> Jonathan,
>>
>> I'll give it a try. Thanks.
>>
>>
>> What is the problem with the mailing list software? Can't handle rich-text?
>> What a pain!
>
> I don’t know if that is true, but if so, a lot o
On 30 September 2014 01:08, George R Goffe wrote:
> Hi,
>
> I'm trying to get some help here.
>
> I have two problems
> with the mailing list software. #1) I have tried to get into digest mode
> by unsubscribing and re-subscribing to the list but that's not working.
> #2) I'm trying to get some hel
On 4 October 2014 15:47, Manuel López-Ibáñez wrote:
> The trivial one is that you build a plugin
> (https://gcc.gnu.org/onlinedocs/gccint/Plugins.html) and hook it at
> PLUGIN_FINISH_DECL (and perhaps also at PLUGIN_FINISH_TYPE, not sure
> about that). You can then run the plugin in the same comman
On 5 October 2014 20:29, Ali Abdul Ghani wrote:
> gcc Became very bad
Unsubstantiated nonsense that has nothing to do with the thread you're
replying to.
> gcc Became the slower and more errors
If you have evidence for this please report it to bugzilla with code
to reproduce the problem.
On 14 October 2014 00:01, Martin Uecker wrote:
> Manuel López-Ibáñez :
>
> Thank you for your quick response.
>
>> > Could we have an option to turn these warnings off?
>>
>> This will be controlled by a new option in GCC 5.0.
>>
>> For the details and the answer to your other questions, see
>> htt
201 - 300 of 2300 matches
Mail list logo
