godbolt.org: https://godbolt.org/z/8oT4Kr5eM
Regards,
Markus Faehling
he SC well.
Best regards
Markus
On Tue, Mar 30, 2021 at 3:20 PM Giacomo Tesio wrote:
>
> Hi Nathan and hello everybody,
>
> On Fri, 26 Mar 2021 16:02:30 -0400 Nathan Sidwell wrote:
>
> > The USA is not the world and the SC is not the US government. For
> > those in the US
nd this very hard to read and I also think that if types become too
complicated or too long to type, something else is wrong.
Regards,
markus.
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisensch
um 16:08 Uhr
> Von: "Alexander Monakov"
> An: "Richard Earnshaw (lists)"
> Cc: "Paul Koning" , "Markus Fröschle"
> , gcc@gcc.gnu.org
> Betreff: Re: asking for __attribute__((aligned()) clarification
>
> On Mon, 19 Aug 2019, Richard Earnshaw (l
If yes, can we have
documentation upgraded to clearly state that this use case is valid?
Thank you.
Markus
0.0/
Unfortunately it is incompatible with mpc-1.0.3.
Once a new mpc version gets released contrib/download_prerequisites
could be updated.
--
Markus
On 2017.12.15 at 10:21 +0100, Paulo Matos wrote:
>
>
> On 15/12/17 08:42, Markus Trippelsdorf wrote:
> >
> > I don't think this is good news at all.
> >
>
> As I pointed out in a reply to Chris, I haven't seeked permission but I
> am pretty sure
r, etc.) of the bot. As a result variance
goes to the roof and all measurements drown in noise.
So it would be good if there was a strict separation of machines used
for bots and machines used by humans. In other words bots should only
run on dedicated machines.
--
Markus
On 2017.10.11 at 08:22 +0200, Paulo Matos wrote:
>
>
> On 11/10/17 06:17, Markus Trippelsdorf wrote:
> > On 2017.10.10 at 21:45 +0200, Paulo Matos wrote:
> >> Hi all,
> >>
> >> It's almost 3 weeks since I last posted on GCC Buildbot. Here's an
causes random gcc crashes. Not the
best setup for a regression tester...
--
Markus
ason for staying with the old 2.2.7a libtool ?
> If not, then does anyone object to my upgrading the gcc, gdb and
> binutils mainline sources ?
Last time I've looked in 2011, libtool's "with_sysroot" was not
compatible with gcc's. So a naive copy doesn't work. But reverting
commit 3334f7ed5851ef1 in libtool before copying should work.
--
Markus
g would work. But running the testsuite takes much to long to
make this approach feasible.
--
Markus
M, Martin Liška wrote:
> >>>> On 09/14/2017 12:07 PM, Markus Trippelsdorf wrote:
> >>>>> On 2017.09.14 at 11:57 +0200, Richard Biener wrote:
> >>>>>> On Wed, Sep 13, 2017 at 6:11 PM, Nikos Chantziaras
> >>>>>> wrote:
> &
internal compiler errors
> we hit. The other issue is that there's no benefit of turning those on for
> SPEC CPU benchmarking as far as I remember but quite a bit of extra
> compile-time cost.
Not to mention the numerous wrong-code bugs. IMHO graphite should
deprecated as soon as possible.
--
Markus
cc1 is on the futex. as is waiting to read. Could that hang be
> related to what's being discussed here?
No. Ryzen is buggy. If you have a chip that was produced before June
this year, your only option is to RMA it.
--
Markus
On 2017.08.29 at 12:53 +0200, Martin Liška wrote:
> On 08/29/2017 12:47 PM, Markus Trippelsdorf wrote:
> > On 2017.08.29 at 12:42 +0200, Martin Liška wrote:
> >> On 08/29/2017 12:39 PM, Martin Liška wrote:
> >>> (gdb) bt
> >>> #0 0x3fff950e58e4 in
; futex(0x3fffa5226d40, FUTEX_WAIT, 0, NULL) = -1 EAGAIN (Resource temporarily
> unavailable)
To me the whole issue looks related to PR81931.
Are you using a clean build directory? Make sure you have the r251328
fix.
--
Markus
On 2017.08.29 at 12:35 +0200, Markus Trippelsdorf wrote:
> On 2017.08.29 at 12:31 +0200, Marco Varlese wrote:
> > Hi,
> >
> > I got a SEGFAULT in my program when compiling it with gcc-7 but it
> > is/was all good when using gcc-6.
> >
> > The SEGFAULT hap
has been:
> memcpy(&d_point,
> p,
> sizeof(d_point));
>
> Does this make any sense to anybody?
No. Please open a bug and attach the full program that causes the crash.
Otherwise the issue is impossible to debug.
--
Markus
On 2017.08.26 at 17:18 +0200, Sylvestre Ledru wrote:
>
>
> On 26/08/2017 13:10, Markus Trippelsdorf wrote:
> > On 2017.08.26 at 13:04 +0200, Sylvestre Ledru wrote:
> >> Hello,
> >>
> >> I have been trying to build the llvm toolchain with gcc 7.2 using
phase (too strong
> optim?)
>
> I haven't seen something relevant to this in the gcc release notes.
>
> More information here:
> https://bugs.llvm.org/show_bug.cgi?id=34140
>
> Does it ring a bell for anyone?
Try building without -gsplit-dwarf?
--
Markus
On 2017.08.26 at 12:40 +0200, Allan Sandfeld Jensen wrote:
> On Samstag, 26. August 2017 10:56:16 CEST Markus Trippelsdorf wrote:
> > On 2017.08.26 at 01:39 -0700, Andrew Pinski wrote:
> > > First let me put into some perspective on -Os usage and some history:
> > > 1
fic size.
For many applications using -flto does reduce code size more than just
going from -O2 to -Os.
--
Markus
her than
> just an ICE.
"internal compiler error: Killed" is almost always an out of memory
error. dmesg will show that the OOM killer kicked in and killed the
cc1plus process.
> The system has 858Mb of RAM without the swap file.
>
> Building a single source file seems to use up to 97% of the available memory
> (for a 2522 line C++ source file).
>
> make -j2 is enough to cause the failure.
Well, you should really use a cross compiler for this setup.
--
Markus
On 2017.05.23 at 05:26 -0400, Aldy Hernandez wrote:
> Jason Merrill writes:
>
> > Yes, the git mirror can lag the SVN repo by a few minutes, that's why
> > you need to 'git svn rebase' to pull directly from SVN before a
> > commit.
> >
> > Jason
On 2017.05.18 at 13:42 -0600, Martin Sebor wrote:
> On 05/18/2017 12:55 PM, Markus Trippelsdorf wrote:
> > On 2017.05.18 at 12:41 -0600, Martin Sebor wrote:
> > > On 05/18/2017 11:59 AM, Jeff Law wrote:
> > > > On 05/18/2017 11:41 AM, Martin Sebor wrote:
> > >
least 10), so clearing these things up takes
> time. Some (I'd say most) of the errors I've seen out of
> Git-svn are also not completely intuitive so it's not always
> clear what or where the problem is.
>
> So I'd like to see if there's something that can be done to
> move the migration forward.
The same issue also happen with git when several people push at the same
time.
--
Markus
n gcc-7_1_0-release
I've added the tag.
--
Markus
e if this email goes through the machines that are having problems
> it may not get anywhere
Yes, looks like the sourceware server is having problems:
https://check-host.net/check-ping?host=gcc.gnu.org
--
Markus
On 2017.04.10 at 13:14 +0100, Richard Earnshaw (lists) wrote:
> On 10/04/17 12:06, Segher Boessenkool wrote:
> > On Mon, Apr 10, 2017 at 12:52:15PM +0200, Markus Trippelsdorf wrote:
> >>> --param ggc-min-heapsize=131072
> >>> 11264.89user 311.88system 24:18.69e
On 2017.04.10 at 12:15 +0200, Markus Trippelsdorf wrote:
> On 2017.04.10 at 10:56 +0100, Richard Earnshaw (lists) wrote:
> >
> > What are the numbers with 256M?
>
> Here are the numbers from a 4core/8thread 16GB RAM Skylake machine.
> They look less stellar than the ppc6
On 2017.04.10 at 10:56 +0100, Richard Earnshaw (lists) wrote:
> On 09/04/17 21:06, Markus Trippelsdorf wrote:
> > On 2017.04.09 at 21:10 +0200, Markus Trippelsdorf wrote:
> >> On 2017.04.09 at 21:25 +0300, Alexander Monakov wrote:
> >>> On Sun, 9 Apr 2
On 2017.04.09 at 21:10 +0200, Markus Trippelsdorf wrote:
> On 2017.04.09 at 21:25 +0300, Alexander Monakov wrote:
> > On Sun, 9 Apr 2017, Markus Trippelsdorf wrote:
> >
> > > The minimum size heuristic for the garbage collector's heap, before it
> > > starts
On 2017.04.09 at 20:23 +0200, Richard Biener wrote:
> On Sun, Apr 9, 2017 at 4:41 PM, Markus Trippelsdorf
> wrote:
> > The minimum size heuristic for the garbage collector's heap, before it
> > starts collecting, was last updated over ten years ago.
> > It curren
On 2017.04.09 at 21:25 +0300, Alexander Monakov wrote:
> On Sun, 9 Apr 2017, Markus Trippelsdorf wrote:
>
> > The minimum size heuristic for the garbage collector's heap, before it
> > starts collecting, was last updated over ten years ago.
> > It currently ha
istic (void)
phys_kbytes = MIN (phys_kbytes, limit_kbytes);
phys_kbytes = MAX (phys_kbytes, 4 * 1024);
- phys_kbytes = MIN (phys_kbytes, 128 * 1024);
+ phys_kbytes = MIN (phys_kbytes, 1000 * 1024);
return phys_kbytes;
}
--
Markus
NULL;
>gimplify_stmt (&DECL_SAVED_TREE (fndecl), &seq);
Haha, your option also has dramatic binary size saving effects.
I would suggest to enable it unconditionally on every April Fools' Day.
--
Markus
to build a whole
>distro. On my Gentoo test box anything but level 1 is simply
>unacceptable, because you will miss important other warnings
>in the -Wimplicit-fallthrough noise otherwise.
The quotation doesn't have anything to do with the current discussion,
which is the general usefulness of the warning.
It only talks about one of the (admittedly over-engineered) six
different levels of the warning.
--
Markus
On 2017.03.27 at 07:44 -0700, Steve Kargl wrote:
> On Mon, Mar 27, 2017 at 03:39:37PM +0200, Markus Trippelsdorf wrote:
> >
> > Well, a missing break is a bug. No?
>
> Every 'case' statement without exception must be accompanied by
> a 'break' state
On 2017.03.27 at 06:26 -0700, Steve Kargl wrote:
> On Mon, Mar 27, 2017 at 08:58:43AM +0200, Markus Trippelsdorf wrote:
> > On 2017.03.26 at 19:30 -0700, Steve Kargl wrote:
> > > On Sun, Mar 26, 2017 at 06:45:07PM -0700, Jerry DeLisle wrote:
> > > > On 03/26/20
e's preferred markup of
> adding a comment to explicitly note a fall through. Candidate
> individual to complain to
>
> If he added a new option affecting libgfortran, then he should
> fix up libgfortran.
He didn't add the warning to specifically annoy fortran developers.
It is trivial to add seven gcc_fallthrough() or breaks for someone who
knows the code and the person who added the warning obviously doesn't.
--
Markus
On 2016.12.11 at 09:59 -0500, Jason Merrill wrote:
> On Dec 11, 2016 2:41 AM, "Markus Trippelsdorf"
> wrote:
> > The git server seems to be stuck for over a day.
> > Latest revision on it is r243504.
> > Latest svn revision is r243523.
> Yes, someone branched
The git server seems to be stuck for over a day.
Latest revision on it is r243504.
Latest svn revision is r243523.
--
Markus
> behavior I'm unknowingly invoking in the code, or it may be a code
> generation bug in gcc. I tried to isolate the exact gcc commit that
> caused the change, but I got stuck...
You should check this first by compiling with -fsanitize=undefined and
fixing all issues that may pop up.
--
Markus
GCC bug?
I don't think so. All compilers (clang, icc, visual C++) behave the
same.
Also these kinds of questions regarding the C++ standard should be asked
on a more appropriate forum like stackoverflow.com or the ISO C++ group:
https://groups.google.com/a/isocpp.org/forum/?fromgroups#!forum/std-discussion
--
Markus
e read the
comments in gcc/diagnostic-color.c.
--
Markus
an either use -fno-diagnostics-color in your CFLAGS or configure
gcc with: --with-diagnostics-color=never.
--
Markus
... The side effect of updating the stored value of the left operand
> shall occur between the previous and the next sequence point."
No. We discussed this on IRC today and Richard Biener pointed out that
bar cannot make c point to &c - 8, because computing that pointer would
be invalid. So c->f1_ cannot clobber c itself.
--
Markus
delete-null-pointer-checks.
So the kernel obviously is already using its own C dialect, that is
pretty far from standard C.
All these options also have a negative impact on the performance of the
generated code.
--
Markus
t page just
> points to the mailing list archive. There is no option to subscribe
> it.
https://sourceware.org/lists.html#ml-requestor
--
Markus
e googletest in their testsuite may be affected.
I've opened: https://github.com/google/googletest/issues/705
--
Markus
nd
crash for this reason. -fno-delete-null-pointer-checks is a workaround.
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68853 for an analysis
of the Chromium crash.
--
Markus
filed. couldn't seem to find docs for how
> to request this, so spamming this list.
Just log in with your gcc email address...
--
Markus
On 2015.11.23 at 11:11 -0800, Steven Noonan wrote:
> On Tue, Nov 17, 2015 at 1:09 AM, Markus Trippelsdorf
> wrote:
> > On 2015.11.16 at 14:18 -0800, Steven Noonan wrote:
> >> Hi folks,
> >>
> >> (I'm not subscribed to the list, so please CC me on all re
t; case would need to compile correctly to an object file -- so "delta"
> is reducing it very slowly. So far I'm down from 11MB preprocessed
> source to 1.1MB preprocessed source after running delta a few times.
These undefined references are normally user errors. For exampl
sue still persists, please post the exact errors that you
encounter.
--
Markus
correlate with ChangeLogs,
> etc.) Won't that work better than the ML archives?
Another possibility would be to simply use the @gcc.gnu.org addresses.
That should make the mapping pretty straightforward.
--
Markus
y frustrating thing for me is "git bisect" doesn't always
> work. I think cherry-pick is OK, but probably not rebase nor merge.
>
> Can we enforce that "git bisect" must work on official branches?
The Linux kernel uses merges all the time, yet "git bisect" works
without any issues. So this not a reason to forbid merges.
BTW while I have your attention: Why are you constantly creating
(rebasing) and deleting branches? Why not simply use a local git tree
for this purpose?
--
Markus
> work. If you still get a failure, this is a pre-existing bug.
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66468 for a small
testcase.
It looks like this is not a pre-existing issue, because with your
sanity check there is not failure.
--
Markus
disabled: 57m12s (99.33%)
Measuring the impact on bigger projects that use pch like QT or Boost
would be more informative perhaps.
And until C++ modules are implemented (unfortunately nobody is working
on this AFAIK) pch is still the only option left. So deprecating them
now seem premature.
--
Markus
On 2015.05.07 at 13:46 -0500, Jason Merrill wrote:
> I think it's time to switch to C++11 as the default C++ dialect for GCC
> 6. Any thoughts?
Why not C++14?
--
Markus
On 2015.03.21 at 12:11 -0400, Jack Howarth wrote:
> On Sat, Mar 21, 2015 at 1:45 AM, Markus Trippelsdorf
> wrote:
> > On 2015.03.20 at 20:08 -0400, Jack Howarth wrote:
> >> What was the final decision concerning future versioning of FSF
> >> gcc post-5.0? In p
if it is 5.1, then after branching for release of
> 5.0, trunk will become 6.0, no?
http://gcc.gnu.org/develop.html#num_scheme
--
Markus
gcc-help is more appropriate for this kind of question.
If you compile with gcc-5 and -fsanitize=undefined you'll get:
mystring.cpp:104:26: runtime error: null pointer passed as argument 2, which is
declared to never be null
So you should guard the memcpy() call.
--
Markus
On 2014.11.21 at 16:16 +0100, Toon Moene wrote:
> See: https://gcc.gnu.org/ml/gcc-testresults/2014-11/msg02259.html
>
> What's not in the log file sent to gcc-results:
See: http://thread.gmane.org/gmane.comp.gcc.patches/327449
--
Markus
Am 13.11.2014 um 14:08 schrieb Fabien Chêne:
> Perhaps that would make sense to mention the existence of the compile
> farm, and add link to it.
Good idea. Bonus points for adding a script which executes all the required
steps.
Markus
--
- - - - - - - - - - - - - - - - - - -
Dipl. In
defines like
__ARM_LPC1114__, __ARM_STM32F405__, etc.
- How would we proceed in general?
- Many flavours at once, or better start with one or two, adding more when
these work?
- Did AVR support make things we should not repeat?
Thanks for discussing,
Markus
P.S.: arm-libc discussion so f
> a.c:6:11: error: overriding final function ‘virtual Base::~Base()’
> virtual ~Base() final {}
What about:
class Derived final: public Base {};
--
Markus
On 2014.09.19 at 14:55 +0200, Markus Trippelsdorf wrote:
> On 2014.09.19 at 13:15 +0100, Rogelio Serrano wrote:
> > /home/rogelio/gcc-build/./prev-gcc/g++
> > -B/home/rogelio/gcc-build/./prev-gcc/ -B/x86_64-unknown-linux-gnu/bin/
> > -nostdinc++
> > -B/home/rogelio/gc
g=bootstrap-lto
>
> then did a profiledbootstrap make
When using profiledbootstrap you should add --disable-werror to the
configuration flags.
--
Markus
to narrow down the issue is to use git (or svn) bisect to
find out which gcc revision causes the miscompile. Then you can md5sum
the kernel object files for the bad revision and for the first good
revision and compare the results. After that you can look at the
disassembly of the object files, for which md5sum differs, and try to
figure out the reason why.
--
Markus
r, the next release should be 10.0, not 5.0.
>
> 10.0 would be even better from a marketing perspective.
Since gcc is released annually why not tie the version to the year of
the release, instead of choosing an arbitrary number?
15.o
--
Markus
gt; find a way to accelerate the compilation in a single file. Can we
> change some serial process into
>
> Parallel? Could you give me some advices? Thank you very much.
Compiling with -flto= and gcc-4.9 should help.
--
Markus
SlipAsciiEntry entry(name, &head, SlipHashEntry::DEFINED);
> SlipHash::ReturnTuple tuple = hashTable->insert(entry);
> if (tuple.condition == SlipHash::ReturnTuple::INSERTED) {
> retval == true; //
> skipped over
retval = true;
--
Markus
bfd-plugin. See for example the
> instructions at http://llvm.org/docs/GoldPlugin.html.
Please note that this automatic loading of the plugin only happens for
non-ELF files. So the LLVM GoldPlugin gets loaded fine, but automatic
loading of gcc's liblto_plugin.so doesn't work at the moment.
A basic implementation to support both plugins seamlessly should be
pretty straightforward, because LLVM's bitstream file format (non-ELF)
is easily distinguishable from gcc's output (standard ELF with special
sections).
--
Markus
On 2014.02.04 at 12:36 +0530, Prathamesh Kulkarni wrote:
> Ping ?
Patches should be posted to the gcc-patc...@gcc.gnu.org list.
Please follow up there.
--
Markus
: 6.98 0.53 7.52
205018
Would it be possible to rearrange the compilation order, so that the
interceptors would be build first (and not last as currently)?
--
Markus
On 2013.07.02 at 19:53 +0200, Thomas Schwinge wrote:
> Hi!
>
> On Sat, 13 Apr 2013 19:25:28 +0200, Markus Trippelsdorf
> wrote:
> > I've attached a gcc_authors file (gathered from various sources), that
> > could be
> > used as a start.
>
> > thomas
directory's permissions and now the build is continuing.
Regards,
Arjen
2013/6/20 Angelo Graziosi :
> Hi Arjen,
>
> Il 20/06/2013 21.41, Arjen Markus ha scritto:
>
>> I found a reference to this sort of problems in the Cygwin FAQs, but
>> this turned out to be a dead-end
ch is necessary for libgmp. That
file is nowhere in the build directory.
So now I am definitely stuck. I can try to contact the Gygwin people
and hope for the best. Or any of
you might know the solution wrt MinGW.
Regards,
Arjen
2013/6/20 Arjen Markus :
> Hi Angelo,
>
> well, contact
Hi Jonathan,
thanks - I did indeed overlook it ;).
Regards,
Arjen
2013/6/20 Jonathan Wakely :
> On 20 June 2013 11:00, Arjen Markus wrote:
>> Hi Angelo,
>>
>> well, the DOS-style path only caused a warning in the configure step,
>> so I assumed it was okay.
>>
Hi Angelo,
well, contacting the Cygwin people is my next step.
Regards,
Arjen
2013/6/20 Angelo Graziosi :
> Il 20/06/2013 12.00, Arjen Markus ha scritto:
>
>> So, I tried again. The problem I reported before has gone, but I still
>> get a file permission problem later on.
>
very much like to hear
about it. My Google foo is failing me
in unearthing a definite solution, I am afraid.
Regards,
Arjen
2013/6/19 Angelo Graziosi :
> Ciao Arjen,
>
> Il 19/06/2013 21.01, Arjen Markus ha scritto:
>
>>
>> As for the build experiment itself:
>> -
reaction. I will see if I can analyse it further.
Regards,
Arjen
2013/6/19 Angelo Graziosi :
> Arjen Markus wrote:
>>
>> I am trying to compile GCC 4.8.1 under Cygwin.
>> ../.././gcc/ada/gcc-interface/Make-lang.in:677: *** target pattern
>> contains no `%'. Sto
On 2013.04.14 at 11:09 +0300, Kalle Olavi Niemitalo wrote:
> Markus Trippelsdorf writes:
>
> > To fix all previous git commits on the mirror one may use the attached
> > git-svn-fix-author script.
>
> Alternatively, you could reformat gcc_authors as a mailmap file
&g
s git commits on the mirror one may use the attached
git-svn-fix-author script.
--
Markus
aaronavay62 = Aaron W. LaFramboise
3dw4rd = Edward Smith-Rowland <3dw...@verizon.net>
emsr = Edward Smith-Rowland <3dw...@verizon.net>
aaw = Ollie Wild
abel = Andrey Belevantsev
adam = Adam M
05447316a6.
> error: Fetch failed.
Please try the git protocol instead of http:
git clone git://gcc.gnu.org/git/gcc.git gcc.git
--
Markus
On 2013.03.25 at 15:17 +0100, Richard Biener wrote:
> On Mon, Mar 25, 2013 at 2:24 PM, Markus Trippelsdorf
> wrote:
> > On 2013.03.25 at 14:11 +0100, Richard Biener wrote:
> >> On Mon, Mar 25, 2013 at 1:56 PM, Markus Trippelsdorf
> >> wrote:
> >>
On 2013.03.25 at 14:11 +0100, Richard Biener wrote:
> On Mon, Mar 25, 2013 at 1:56 PM, Markus Trippelsdorf
> wrote:
> > On 2013.03.25 at 08:06 +0100, Markus Trippelsdorf wrote:
> >> On 2013.03.24 at 20:53 +0100, gcc_mailingl...@abwesend.de wrote:
> >> >
> &g
On 2013.03.25 at 06:07 -0700, Andi Kleen wrote:
> Markus Trippelsdorf writes:
> >
> > So it appears, contrary to the advice given above, that it is not useful
> > to build gcc 4.8.0 with the lto option at the moment.
>
> Did you build firefox/kernel with debug info on
On 2013.03.25 at 08:06 +0100, Markus Trippelsdorf wrote:
> On 2013.03.24 at 20:53 +0100, gcc_mailingl...@abwesend.de wrote:
> >
> > is it useful to compile gcc 4.8.0 with the lto option?
>
> If you want a (slightly) faster compiler then yes.
> Simply add "--with-b
Resolution Summary
54114 nor P1 unassigned NEW --- [4.8/4.9 Regression]
variable-tracking performance regression from 4.8-20120610 to 4.8-20120701
49234 min P2 aldyh NEW --- [4.6/4.7/4.8/4.9 Regression]
-Wstrict-overflow gives obviously unwarranted warning
...
--
Markus
plementation
doesn't catch this particular issue yet.
--
Markus
Is there any interest in updating the in-tree libtool to something
newer? This update would allow to use a -fno-fat-lto-objects
lto-bootstrap target, that should speed up the (lto) build time.
If there is interest, when would be the best date for such an update?
Thanks.
--
Markus
expects. I'm not really an expert in this area so I wanted to report it
> here so that more knowledgeable people can decide how to solve the issue...
FYI, the gcc bug can be found here:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52080
--
Markus
gt;
> 2012-01-23 08:26:38.652665266 +0100
> @@ -8375,7 +8375,7 @@
> {
> &ipa_escaped_pt.vars,
> 1,
> -sizeof (ipa_escaped_pt.vars),
> +sizeof (ipa_escaped_pt),
> >_ggc_mx_bitmap_head_def,
> >_pch_nx_bitmap_head_def
> },
> ...
>
>
> Any ideas about the cause?
I've opened a bug for this issue:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51969
It only happens if you try to build gcc-4.6 with gcc-4.7 on my machine.
--
Markus
e sync with upstream would be the best option IMO.
--
Markus
Revisions 176335 removed the traditional "#include " from
gthr-posix.h. This breaks the build of many programs (Firefox, Chromium,
etc.) that implicitly rely on it.
I'm not sure that the gain is worth the pain in this case.
--
Markus
On 2011.07.17 at 18:54 +0200, Markus Trippelsdorf wrote:
> On 2011.07.17 at 18:30 +0200, Richard Guenther wrote:
> > On Sun, Jul 17, 2011 at 1:30 PM, Eric Botcazou
> > wrote:
> > >> I have measured it at some point and IIRC it was about 10% slower
> > >> (
xit
--enable-clocale=gnu --with-build-config=bootstrap-lto
And built with:
make -j4 BOOT_CFLAGS="-march=native -O2 -pipe"
STAGE1_CFLAGS="-march=native -O2 -pipe" CFLAGS_FOR_TARGET="-march=native
-O2 -pipe" profiledbootstrap
--
Markus
1 - 100 of 131 matches
Mail list logo
