iously...
>
> On Fri, 29 Dec 2017 19:40:38 -0800 Eric Gallager
> wrote
> > On 12/29/17, Louis Krupp wrote:
> > > I tried to build the trunk using:
> > >
> > > BOOT_CFLAGS='-g -Og' CFLAGS_FOR_TARGET='-g -Og' CFLAGS_FOR
> This HOST_WIDE_INT is defined in gcc/hwint.h. Who is supposed to include
> this file? Is this done via an #include or via a tm_file (gcc/config.gcc)?
Nobody I'd say, the declaration shouldn't be compiled for the target.
--
Eric Botcazou
, right? (For reference, Meltdown is CVE-2017-5754,
and Spectre is CVE-2017-5753 and CVE-2017-5715)
Just wondering,
Eric
On 1/4/18, Will Hawkins wrote:
> On Thu, Jan 4, 2018 at 10:10 PM, Eric Gallager
> wrote:
>> Is there anything GCC could be doing at the compiler level to mitigate
>> the recently-announced Meltdown and Spectre vulnerabilities? From
>> reading about them, it seems like
On 1/5/18, Eric Gallager wrote:
> On 1/4/18, Will Hawkins wrote:
>> On Thu, Jan 4, 2018 at 10:10 PM, Eric Gallager
>> wrote:
>>> Is there anything GCC could be doing at the compiler level to mitigate
>>> the recently-announced Meltdown and Spectre vulnerabili
On 1/17/18, Martin Jambor wrote:
> Hi,
>
> following a discussion at IRC about an upcoming deadline to register GCC
> as an independent organization for Google Summer of Code 2018 (GSoC), I
> have volunteered to serve as the org-admin for GCC if:
>
> - there is not another volunteer (so step up
atency of the loads (assuming some AVR processors are pipelined),
in which case CCmode will give you a performance bonus.
--
Eric Botcazou
On 1/18/18, Frank Ch. Eigler wrote:
>
> msebor wrote:
>
>> I'm having trouble bringing up bugs or updating them. Has anyone else
>> noticed Bugzilla (and/or other services running on gcc.gnu.org) being
>> very slow or timing out?
>
> One failed disk in the server has been replaced yesterday. Ple
ew back-end. And IMO starting from scratch is a bad idea.
> But writing a backend is too much for a GSoC, even a small one.
Definitely, and doing a CC0 conversion is probably an upper bound.
--
Eric Botcazou
tes is given by tree.c:bit_position/byte_position.
--
Eric Botcazou
d
> 23_containers/unordered_set/requirements/exception/propagation_consistent.cc
Does passing -fno-reorder-blocks-and-partition change anything?
--
Eric Botcazou
> Sorry for the stupid question. How do I pass this to the testsuite?
For ACATS it's a little awkward: you manually need to add it to the gccflags
variable in gcc/testsuite/ada/acats/run_all.sh
--
Eric Botcazou
2102m ce2103a ce2103b ce3102d ce3107a ce3115a cxa4005 cxa4008
> cxa4016 cxa4019 cxac003 cxb3012 cxf3a01 cxf3a02
> /opt/devel/gnu/src/gcc-mingw-w64/gcc-8.0.0/gcc/testsuite/ada/acats/run_all.s
> h completed at Wed Feb 7 12:28:36 CET 2018
Please open a PR for the ACATS regressions on mainline.
--
Eric Botcazou
fixed" it?
What are the requirements imposed on setjmp exactly and by whom? The psABI on
SPARC (the SCD) has an explicit note saying that setjmp/sigsetjmp/vfork don't
(have to) preserve the usual non-volatile registers.
--
Eric Botcazou
the (historical) requirements were vague
enough to allow their interpretation, IOW that the compiler can do the work.
--
Eric Botcazou
GNU and the Solaris libc make use of
the leeway given by the psABI for setjmp at least in some cases.
--
Eric Botcazou
> Maybe we should have a target hook that says setjmp/longjmp are
> implemented by simple function calls (or as-if by function calls), so
> as not to penalize everyone who has an, erm, more conservative ABI?
Yes, that sounds a sensible compromise to me.
--
Eric Botcazou
ch for the website's changes.html, covering the
> same material.
>
> Dave
>
Thank you re: the updating the changes.html part; I was thinking it
was looking rather bare compared to previous changes.html pages at
this same point in previous release cycles...
Eric
ich doesn't really make sense IMO.
--
Eric Botcazou
ng them at P3, which is not "don't care" as far as I
know but just the default priority. The criterion could be a flag that is not
part of any -Ox switches and not enabled on any primary+secondary platforms.
--
Eric Botcazou
Confirming, I got the same error message at around 7:29 AM Eastern
Daylight Time. Please fix!
Eric
On 4/1/18, Thomas König wrote:
> Hi,
>
> it seems that gcc bugzilla is currently down, error message is:
>
> Software error:
>
> Can't connect to the database.
>
On 4/2/18, Martin Sebor wrote:
> Jason,
>
> The manual mentions some C++-only options in the language
> independent section 3.8 Options to Request or Suppress
> Warnings and others in 3.5 Options Controlling C++ Dialect.
>
> For example, -Wcatch-value, -Wconditionally-supported,
> and -Wzero-as-nu
On 4/19/18, Manish Jain wrote:
> Hi all,
>
> One of the historical artefacts of the C language has been the burden of
> lugging around multiple declarations in a single statement, with some
> well-known pitfalls:
>
> int* ptr1, ptr2;
>
> Since ptr2 looks like a pointer but actually is not, standar
gisters, whereas for structures it's dependent on
the types of the fields.
> Could anyone provide some insight on whether the TYPE_MODE of a union should
> stay as a MODE_INT class or if it would be acceptable for the TYPE_MODE to
> be other classes e.g. MODE_FLOAT?
No, I don't think we want to change that.
--
Eric Botcazou
> Is this something the back end is responsible for getting right, for example
> via the machine description file? If so, any hints where to start?
The SUBREG of MEM is invalid at this stage.
--
Eric Botcazou
term with cases that do
require symbolic information to optimize things? The TODO page seems to
acknowledge the loophole but only mentions a plan to deal with equivalences,
which is not sufficient in the general case (as acknowledged too on the page).
--
Eric Botcazou
etting aside the
handling of symbolic information might end up being a good compromise between
the necessary minimal[*] handling of this information and the complexity of
doing it directly in the Ranger.
[*] The implicit assumption hee is that a VRP implementation with full-blown
support of symbolic ranges is not worth the hassle in practice.
--
Eric Botcazou
> Any ideas about how to resolve this?
Compare with a known working version (e.g. GCC 7) and find the discrepancy.
--
Eric Botcazou
ols build (gnatdll to be precise).
--
Eric Botcazou
On 6/27/18, Marek Polacek wrote:
> On Wed, Jun 27, 2018 at 08:53:48AM -0700, Steve Ellcey wrote:
>> Are other people building GCC seeing these messages during the build:
>>
>> cc1plus: warning: -Wabi won't warn about anything [-Wabi]
>> cc1plus: note: -Wabi warns about differences from the most up
On 6/29/18, Martin Liška wrote:
> Hi.
>
> I would like to add some DejaGNU tests for completion option.
>
> Ready for trunk?
> Martin
>
So, correct me if I'm wrong, but these tests would need to be updated
every time a new option starting like one of those is added, right? If
so, can you think of
visit the bug reporter during the day. Also
> see https://gcc.gnu.org/ml/gcc-help/2017-08/msg00092.html .
>
> Jeff
>
It was down for me last night and earlier this morning, too, but it
seems to be back up now.
Eric
> Is there any builtin function in C which prints the virtual address of
> functions including the main? I see __builtin_return_address() but that
> returns the “return address”.
This list is not appropriate for such a question, use gcc-help@ instead.
--
Eric Botcazou
r_with_msg?
No one, it's obsolete. The port is very likely not (properly) configured.
--
Eric Botcazou
_Default: constant Boolean := False;
in system-rtems.ads.
--
Eric Botcazou
> We noticed a difference in the code generated for aarch64 gcc 7.2
> hosted in Linux vs mingw. AFIK, we are supposed to produce the same
> output.
Try maybe to compare the automata generated on the hosts, are they identical?
--
Eric Botcazou
> They are definitely useful in my day-to-day work when tracking down changes
> given I can easily grep them.
Seconded.
> I think that any change here should be _after_ we've switched to git
> (finally).
Well, git doesn't make anything easier than subversion in thi
On 7/5/18, Aldy Hernandez wrote:
> After 20 years of hacking on GCC I feel like I have literally wasted
> days of my life typing out ChangeLog entries that could have easily been
> generated programmatically.
>
> Can someone refresh my memory here, what are the remaining arguments for
> requiring
n and should be combined into a single HImode move. This
> happens both with -O2 and -Os.
The GIMPLE pass responsible for the optimization simply punts for the "funny-
endian ordering" of the PDP11. More generally, you shouldn't expect anything
sparkling for such a peculiar architecture as the PDP11.
--
Eric Botcazou
o do a side-by-side debugging of a compiler built for a
similar target for which only 2 stores are generated.
--
Eric Botcazou
> Xstormy does 3 mov.b also. For that matter, so does the x86 target (both
> -m32 and -m64). Hm.
Indeed, even at -Os, so this may be a generic issue.
--
Eric Botcazou
On 7/19/18, U.Mutlu wrote:
> Hi,
> it makes me 'crazy' when I see such if-else constructs:
>if (x)
> return 7;
>else
> return 4;
>
> (Of course in this case one better would use the shorthand "return x ? 7 :
> 4;", but that's not the issue here)
>
> The 'else' is obviously superf
On 7/19/18, Jeff Law wrote:
> On 07/18/2018 03:28 PM, Segher Boessenkool wrote:
>> On Wed, Jul 18, 2018 at 11:51:36AM +0200, Richard Biener wrote:
>>> We already conditionally require Perl for building for some targets so I
>>> wonder
>>> if using perl would be better ...
>>
>> At least perl is GP
On 7/23/18, Segher Boessenkool wrote:
> On Mon, Jul 23, 2018 at 04:03:31PM +0300, Alexander Monakov wrote:
>> Not necessarily in the source tree: individual users can put that into
>> their
>> $XDG_CONFIG_HOME/git/attributes or $HOME/.config/git/attributes.
>
> And then that user has *all* .md fil
On 7/28/18, Bruce Korb wrote:
> ../../autoopts/makeshell.c: In function ‘text_to_var’:
> ../../autoopts/makeshell.c:324:14: error: this statement may fall
> through [-Werror=implicit-fallthrough=]
> (*(opts->pUsageProc))(opts, EXIT_SUCCESS);
> ~^~~
> Can you point me at least to the section which explains this?
http://gcc.gnu.org/install/build.html
--
Eric Botcazou
> + i386 Ada ICE (regression) - http://gcc.gnu.org/PR47481
I'll look into this one...
> + mips Ada -G0 - http://gcc.gnu.org/PR47500
...but a MIPS maintainer needs to take a preliminary look at this one.
--
Eric Botcazou
so they disable their
manipulation altogether to avoid generating wrong code.
--
Eric Botcazou
> I figured if I knew what was needed before opening the bug it would cut
> down on the need-info requests. Thanks.
The instructions are available on the http://gcc.gnu.org/bugs/ page.
--
Eric Botcazou
ave the same, in particular when they are on the LHS of an assignment.
--
Eric Botcazou
> What does "word" mean here? Is it a 32-bit entity or is it according to
> word_mode which is QImode for avr?
The latter, it is machine-dependent.
> So the same should be true for QI-subregs of scalar modes if
> UNITS_PER_WORT = 1. Right?
Right.
--
Eric Botcazou
y_operand), but I freely admit
> this is a part of the compiler that I'm not familiar with.
SPARC had exactly the same pattern as the 'U' constraint of MMIX. It now uses
reload_in_progress || reload_completed instead (in memory_ok_for_ldd).
--
Eric Botcazou
long?
Probably because you're also fiddling with configure checking options. Avoid
doing that if you aren't familiar with them.
--
Eric Botcazou
his weekends/holidays allowance would be dangerous and counter-productive:
people would rush to install risky changes on Friday and leave for the
week-end fingers crossed. This would be worse than the current policy IMO.
--
Eric Botcazou
e key
> "--disable-checking" configury bits that we were able to confirm a
> problem and start the real process of diagnosing what went wrong.
No, this isn't what happened, see the audit trail of PR48403. This was a big
breakage. --disable-checking had nothing to do with the problem either.
--
Eric Botcazou
> -Original Message-
> From: Steven Bosscher [mailto:stevenb@gmail.com]
> Sent: Tuesday, April 05, 2011 6:24 AM
> To: Bernd Schmidt
> Cc: Ian Lance Taylor; GCC Mailing List; David Edelsohn; Benjamin Kosnik;
> H.J. Lu
> Subject: Re: To Steering Committee: RFC for patch revert policy (PR
_type condition. Would
that work for other languages as well, in particular C++?
--
Eric Botcazou
> LTO bootstrap has been broken for more than a month:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48148
I'm about to submit a fix for the .Ldebug_info0 failure.
--
Eric Botcazou
> I was LTO bootstrapping yesterday just fine. You're talking about
> bootstrap-profiled.
Not clear at all, a regular LTO bootstrap had failed on cc1 for days here.
--
Eric Botcazou
> Hmpf. Strange. I've bootstrapped with all languages except Ada
> yesterday, with gold as plugin-ld.
GNU ld (with plugins) for me, but --enable-checking=yes,rtl. Maybe H.J. had
e.g. --enable-checking=release. In any case, something is brittle ATM.
--
Eric Botcazou
the pass doesn't consume REG_DEAD/REG_UNUSED notes, it doesn't have to keep
them up-to-date. Instead, passes that consume them must df_note_add_problem()
on entry. For the generic reorg (delay slot filling) pass, this is done in
rest_of_pass_free_cfg.
--
Eric Botcazou
e the CFG has been destroyed so it
very likely needs to use a trick akin to that of the generic reorg pass in
rest_of_pass_free_cfg.
--
Eric Botcazou
> rest_of_pass_free_cfg calls df_analyze but it doesn't call
> df_note_add_problem. Is that the issue? I see that some other passes
> (like regrename) do a sequence of df_xyz calls.
It does now, you have outdated sources.
--
Eric Botcazou
eric@eric-laptop:~/practicalCpp$ g++ fixed_pt.cpp fixed_test.cpp
In file included from fixed_pt.cpp:3:
fixed_pt.h:211: error: fixed_pt::fixed_pt fixed_pt::fixed_pt::operator+(const
fixed_pt::fixed_pt&, const fixed_pt::fixed_pt&) must take either zero or one
argument
fixed_pt.h:21
middle-end expects word-mode subregs
of double-word-mode hard regs to be simplifiable.
--
Eric Botcazou
2 %f40) 4) isn't simplifiable either. H.P. wrote a
tentative patch for the subreg machinery to forbid this. Other references are:
http://gcc.gnu.org/ml/gcc-patches/2008-07/msg01688.html
http://gcc.gnu.org/ml/gcc-patches/2008-08/msg01743.html
--
Eric Botcazou
could be applied immediately. The
patches from mainline it is made up of are listed at the end of the message.
Can I proceed with the backport?
2011-06-10 Eric Botcazou
Laurent Rougé
* doc/invoke.texi (SPARC options): Add -mflat.
* config/sparc/sparc.opt: Lik
> Apart from
>
> 2011-06-02 Eric Botcazou
>
>* cse.c (cse_find_path): Refine change to exclude EDGE_ABNORMAL_CALL
>edges only, when there is a non-local label in the function.
>* postreload-gcse.c (bb_has_well_behaved_predecessors): Likewise.
&
or mainline. You get the real testing when you
release and I think that the .1 release would have been appropriate. I'm not
so sure for the .2 release, as this would mean waiting for 4.6.3 to fix the
probable fallouts for the SPARC port. I guess we'd better drop the idea then.
--
Eric Botcazou
wasting
CPU cycles. ;-)
--
Eric Botcazou
think CPU cycles
> wouldn't be wasted by preparing a fix for 4.6.2).
I think it is as obviously safe as a reorg.c patch can be so I'm going to test
it (on the branch) and post it afterward, but it will be your call of course.
--
Eric Botcazou
> The immediate blocker to using C++ in gcc is the Ada frontend.
> --enable-build-with-cxx and --enable-languages=ada do not work together.
Could you elaborate?
--
Eric Botcazou
g++ instead of
gcc to link) are needed and extern "C" must be added all over the place, see:
http://gcc.gnu.org/ml/gcc/2009-06/msg00635.html
I can post an updated patch if you want, but saying that the Ada front-end
blocks the use of C++ in gcc is unfair; it is (and has always be
11-07/msg00845.html
> I have a patch ready to go which would use C++ in stages 2 and 3. I
> can't propose that patch right now because it fails when building Ada.
> If we get Ada fixed, I will propose it.
OK, let's fix --enable-build-with-cxx with Ada. Thanks for clarifying.
--
Eric Botcazou
atch, thanks, will fix.
--
Eric Botcazou
COMPILER = $(CC)
> COMPILER_FLAGS = $(CFLAGS)
> LINKER = $(CC)
> LINKER_FLAGS = $(CFLAGS)
> else
> COMPILER = $(CXX)
> COMPILER_FLAGS = $(CXXFLAGS)
> LINKER = $(CXX)
> LINKER_FLAGS = $(CXXFLAGS)
> endif
I'm not sure because I don't think we want to compile the C files of the Ada
runtime with the C++ compiler. We want to do that only for the compiler.
--
Eric Botcazou
ern "C" blocks, I'm
going to clean it up.
--
Eric Botcazou
preferrable.
But your patch isn't necessary to do that, the C files are already compiled
with the C++ compiler as of today; the only issue is at the linking stage.
--
Eric Botcazou
> The problem is that the patches links gnattools unconditionally with
> g++. It should depend on --enable-build-with-cxx instead.
Yes, that part was wrong, it will be dropped, we don't want to use g++ here.
--
Eric Botcazou
I of the target.
Only after Fortran does the same. :-)
--
Eric Botcazou
that your suggestion is the way to go and I made the same when we were
fiddling with boolean_type_node in free_lang_data:
http://gcc.gnu.org/ml/gcc-patches/2009-10/msg00966.html
So fine with me, as long as all the languages play by the same rules.
--
Eric Botcazou
alling cleanup_tree_cfg()
> after my transformation pass, still no luck
Try invoking rebuild_cgraph_edges.
--
Eric Botcazou
> I have measured it at some point and IIRC it was about 10% slower
> (comparing C bootstrap with C++ in stag1 languages with C++ bootstrap,
> not sure if that included bootstrapping libstdc++ for the former).
IMO acceptable now that the build time of libjava has been halved.
--
Eric Botcazou
see name-lookup.c:get_anonymous_namespace_name.
--
Eric Botcazou
> -Original Message-
> From: Joern Rennecke [mailto:amyl...@spamcop.net]
> Sent: Friday, July 22, 2011 9:22 AM
> To: Paulo J. Matos
> Cc: gcc@gcc.gnu.org
> Subject: Re: C99 Status - inttypes.h
>
> I agree that trying to track every library there would be a maintenance
> burden, but givin
> Realistically, how many unique libraries are used for all of the GCC
> targets? I would think that it has to be some low, finite number.
There is at least one per OS (Linux, Solaris, HP-UX, IRIX, Tru64, *BSD, VMS,
Windows, etc) plus variants depending on the version of the OS.
--
> -Original Message-
> From: Eric Botcazou [mailto:ebotca...@adacore.com]
> Sent: Saturday, July 23, 2011 1:28 PM
> To: Weddington, Eric
> Cc: gcc@gcc.gnu.org; Joern Rennecke; Paulo J. Matos
> Subject: Re: C99 Status - inttypes.h
>
> > Realistically, how man
s platform with the right
libraries and GCC as base compiler.
--
Eric Botcazou
area. You'd need to upgrade to
4.5.3 at least (or use the SVN 4.5 branch). That being said, targets with
multiple delay slots are indeed relatively untested.
--
Eric Botcazou
h
more in the V9 manual. Quoting it:
"The order of memory operations observed at a single location is a total order
that preserves the partial orderings of each processor’s transactions to this
address. There may be many legal total orders for a given program’s execution"
--
Eric Botcazou
nt build is targeted on a
different environment?
Any comments or alternative suggestion?
Yours
- Michael
--
Eric Blake ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org
> I'm porting a 64-bit target gcc on a 32-bit i386 host. I have set
> need_64bit_hwint to yes in config.gcc. But it fails when building
> libgcc.
You need to do the same in libcpp/configure.ac with recent versions.
--
Eric Botcazou
get rid of them in any case I'd think.
--
Eric Botcazou
get rid of them in any case I'd think.
--
Eric Botcazou
m beginning to think the whole of a-exexpr-gcc needs to be extracted
> into 2 distinct files, a-exexpr-gcc (normal GCC EH - as it is) and
> a-exexpr-gcc-arm (ARM EABI EH).
Probably some parts of it, yes.
--
Eric Botcazou
ration.
> Is the scenario above intended behavior of the combine pass or an
> accident? Or maybe even something else wrong in the machine description
> that makes it behave like that?
See how the i386 back-end copes with this for its "test" instruction.
--
Eric Botcazou
real_insn depends on -g? And that I have to write my
> own next really_real_insn?
Try prev_active_insn/next_active_insn.
--
Eric Botcazou
The test fails with a link error, as 'round' and 'rint' are only C99.
Fixed thusly, tested on SPARC/Solaris 8, applied on the mainline as obvious.
2011-10-13 Eric Botcazou
* gcc.dg/builtins-67.c: Guard iround and irint with HAVE_C99_RUNTIME.
--
Eric Bo
other
classes) shouldn't depend on the mode but only on the type.
--
Eric Botcazou
> Right and as Richard said I can munge the modes during expansion of
> existing builtins when needed.
OK, but you precisely shouldn't need to do it since the type is fixed.
--
Eric Botcazou
601 - 700 of 1857 matches
Mail list logo
