On 03/27/2017 08:29 PM, Marek Polacek wrote:
On Mon, Mar 27, 2017 at 11:16:32AM -0700, Steve Kargl wrote:
On Mon, Mar 27, 2017 at 07:41:12PM +0200, Marek Polacek wrote:
On Mon, Mar 27, 2017 at 07:33:05PM +0200, Toon Moene wrote:
The person developing the warning could *at least* have bootst
On Mon, Mar 27, 2017 at 11:16:32AM -0700, Steve Kargl wrote:
> On Mon, Mar 27, 2017 at 07:41:12PM +0200, Marek Polacek wrote:
> > On Mon, Mar 27, 2017 at 07:33:05PM +0200, Toon Moene wrote:
> > > On 03/27/2017 06:45 PM, Marek Polacek wrote:
> > >
> > > > On Mon, Mar 27, 2017 at 09:27:34AM -0700, S
On Mon, Mar 27, 2017 at 07:59:01PM +0200, Thomas Koenig wrote:
> Am 27.03.2017 um 19:41 schrieb Marek Polacek:
>
> > Of course "the person" had bootstrapped and tested all the languages before
> > adding the warning. If only any of you bothered to check the fortran/
> > ChangeLogs:
>
> The probl
On 27 March 2017 at 18:59, Thomas Koenig wrote:
> Am 27.03.2017 um 19:41 schrieb Marek Polacek:
>
>> Of course "the person" had bootstrapped and tested all the languages
>> before
>> adding the warning. If only any of you bothered to check the fortran/
>> ChangeLogs:
>
>
> The problem is with lib
On March 27, 2017 7:59:01 PM GMT+02:00, Thomas Koenig
wrote:
>Am 27.03.2017 um 19:41 schrieb Marek Polacek:
>
>> Of course "the person" had bootstrapped and tested all the languages
>before
>> adding the warning. If only any of you bothered to check the
>fortran/
>> ChangeLogs:
>
>The problem is
On Mon, Mar 27, 2017 at 07:41:12PM +0200, Marek Polacek wrote:
> On Mon, Mar 27, 2017 at 07:33:05PM +0200, Toon Moene wrote:
> > On 03/27/2017 06:45 PM, Marek Polacek wrote:
> >
> > > On Mon, Mar 27, 2017 at 09:27:34AM -0700, Steve Kargl wrote:
> >
> > > > But that's okay. I now understand that
Am 27.03.2017 um 19:41 schrieb Marek Polacek:
Of course "the person" had bootstrapped and tested all the languages before
adding the warning. If only any of you bothered to check the fortran/
ChangeLogs:
The problem is with libfortran, which apparently was not tested
(or the problem would hav
On Mon, Mar 27, 2017 at 07:33:05PM +0200, Toon Moene wrote:
> On 03/27/2017 06:45 PM, Marek Polacek wrote:
>
> > On Mon, Mar 27, 2017 at 09:27:34AM -0700, Steve Kargl wrote:
>
> > > But that's okay. I now understand that it is acceptable for
> > > a developer to commit a change that causes issue
On 03/27/2017 06:45 PM, Marek Polacek wrote:
On Mon, Mar 27, 2017 at 09:27:34AM -0700, Steve Kargl wrote:
But that's okay. I now understand that it is acceptable for
a developer to commit a change that causes issues for other
developers, and said developer can turn a blind eye.
Nonsense.
On Mon, Mar 27, 2017 at 06:45:32PM +0200, Marek Polacek wrote:
> On Mon, Mar 27, 2017 at 09:27:34AM -0700, Steve Kargl wrote:
> > On Mon, Mar 27, 2017 at 05:22:12PM +0200, Markus Trippelsdorf wrote:
> > > On 2017.03.27 at 06:49 -0700, Steve Kargl wrote:
> > > >
> > > > Go scan the gcc-patches mail
On Mon, 27 Mar 2017, Davide Piombo wrote:
> Sorry but it is not clear to me if the point is that the plugin
> development must include some windows-related code that I'm actually
> missing or if the problem is on the GCC side, that is inside GCC the
> code section that loads the dll, or part of
On Mon, Mar 27, 2017 at 09:27:34AM -0700, Steve Kargl wrote:
> On Mon, Mar 27, 2017 at 05:22:12PM +0200, Markus Trippelsdorf wrote:
> > On 2017.03.27 at 06:49 -0700, Steve Kargl wrote:
> > >
> > > Go scan the gcc-patches mailing list for "fallthrough". I'll
> > > note other have concerns. Here's
On Mon, Mar 27, 2017 at 05:22:12PM +0200, Markus Trippelsdorf wrote:
> On 2017.03.27 at 06:49 -0700, Steve Kargl wrote:
> >
> > Go scan the gcc-patches mailing list for "fallthrough". I'll
> > note other have concerns. Here's one example:
> >
> > https://gcc.gnu.org/ml/gcc-patches/2016-11/msg00
Hi Joseph,
thanks a lot for your answer.
Sorry but it is not clear to me if the point is that the plugin development
must include some windows-related code that I'm actually missing or if the
problem is on the GCC side, that is inside GCC the code section that loads the
dll, or part of it, is m
Hi Dave,
thanks a lot for your ready answer.
> > The final platform target of the plugin is (unfortunately ;-))
> Windows
> > and = I tried to rebuild the plugin using MinGW compiler (both with
> > the Linux ver= sion as well by using MSYS2 and win-builds MinGW
> > compilers for windows) but= th
On Mon, 27 Mar 2017, David Malcolm wrote:
> > Substantially I'm writing just to ask:
> > Can GCC plugins run on a windows build of GCC compiler (MinGW) ?
>
> I suspect the answer is "you're the first person to try this in a
> while; some things may need fixing" - but that's a guess :)
If it's Wi
On Mon, 27 Mar 2017, carl hansen wrote:
> suggested additions:
>
> get and insert the latest libtool, which includes files:
> libtool.m4 ltgcc.m4 lt~obsolete.m4 ltoptions.m4 ltsugar.m4 ltversion.m4,
> all way-old currently in gcc-7
libtool and auto* updates are only reasonable in developmen
On 2017.03.27 at 06:49 -0700, Steve Kargl wrote:
> On Mon, Mar 27, 2017 at 02:36:27PM +0100, Jonathan Wakely wrote:
> > On 27 March 2017 at 14:26, Steve Kargl wrote:
> > > I completely disagree with your viewpoint here. If someone turns
> > > on a silly warning, that someone should fix all places
On 27 March 2017 at 14:49, Steve Kargl wrote:
> On Mon, Mar 27, 2017 at 02:36:27PM +0100, Jonathan Wakely wrote:
>> On 27 March 2017 at 14:26, Steve Kargl wrote:
>> > I completely disagree with your viewpoint here. If someone turns
>> > on a silly warning, that someone should fix all places within
On 27 March 2017 at 14:49, Steve Kargl wrote:
> On Mon, Mar 27, 2017 at 02:36:27PM +0100, Jonathan Wakely wrote:
>> On 27 March 2017 at 14:26, Steve Kargl wrote:
>> > I completely disagree with your viewpoint here. If someone turns
>> > on a silly warning, that someone should fix all places within
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' statement? Wasting others' time to "fix" working
> c
On Mon, Mar 27, 2017 at 12:18:17PM +0200, Dominique d'Humières wrote:
> > > 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
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' statement? Wasting others' time to "fix" working
correct code is acceptable?
--
Steve
20161221 https://www.yout
On Mon, 2017-03-27 at 11:18 +, Davide Piombo wrote:
> Hello,
> I'm interested in developing a plugin to parse some custom annotation
> in C+=
> + code.
> I already developed a preliminary version of this plugin under linux
> and it= works fine.
Excellent.
> The final platform target of the p
On Mon, Mar 27, 2017 at 02:36:27PM +0100, Jonathan Wakely wrote:
> On 27 March 2017 at 14:26, Steve Kargl wrote:
> > I completely disagree with your viewpoint here. If someone turns
> > on a silly warning, that someone should fix all places within the
> > tree that triggers that warning. There is
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/2017 11:45 AM, Steve Kargl wrote:
> > >
On 27 March 2017 at 14:26, Steve Kargl wrote:
> I completely disagree with your viewpoint here. If someone turns
> on a silly warning, that someone should fix all places within the
> tree that triggers that warning. There is ZERO value to this warning,
> but added work for others to clean up that
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/2017 11:45 AM, Steve Kargl wrote:
> > > > On Sun, Mar 26, 2017 at 11:27:59AM -0700, Jerry DeLisle
Hello,
I'm interested in developing a plugin to parse some custom annotation in C+=
+ code.
I already developed a preliminary version of this plugin under linux and it=
works fine.
The final platform target of the plugin is (unfortunately ;-)) Windows and = I
tried to rebuild the plugin using Mi
> > 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
suggested additions:
get and insert the latest libtool, which includes files:
libtool.m4 ltgcc.m4 lt~obsolete.m4 ltoptions.m4 ltsugar.m4 ltversion.m4,
all way-old currently in gcc-7
get latest autoconf. 2.64 in use, latest is 2.69
get latest texinfo.tex, not one 5 years old
GNU is supposed
31 matches
Mail list logo
