https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69490
--- Comment #3 from Rainer Emrich ---
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Am 26.01.2016 um 16:08 schrieb Rainer Emrich:
> Am 26.01.2016 um 15:50 schrieb dmalcolm at gcc dot gnu.org:
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=694
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69490
Rainer Emrich changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68446
Rainer Emrich changed:
What|Removed |Added
CC||rai...@emrich-ebersheim.de
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69466
--- Comment #5 from Alexandre Oliva ---
Created attachment 37486
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37486&action=edit
Patch I'm testing to fix the problem
The problem occurs because we call set_current_def for phi nodes after
d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68654
--- Comment #22 from rguenther at suse dot de ---
On Tue, 26 Jan 2016, afomin.mailbox at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68654
>
> --- Comment #21 from Alexander Fomin ---
> (In reply to Richard Biener from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69336
--- Comment #11 from Richard Biener ---
Should be fixed with
2016-01-25 Richard Biener
PR testsuite/69380
* g++.dg/tree-ssa/pr69336.C: Restrict to x86_64 and i?86.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69482
--- Comment #5 from rguenther at suse dot de ---
On Wed, 27 Jan 2016, wipedout at yandex dot ru wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69482
>
> --- Comment #4 from wipedout at yandex dot ru ---
> Okay, suppose we have the follow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69466
--- Comment #6 from Richard Biener ---
I'll have a look as well.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69508
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69506
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69408
--- Comment #14 from night_ghost at ykoctpa dot ru ---
Created attachment 37487
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37487&action=edit
script to build GCC-avr and other tools
use this script to build GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69508
--- Comment #2 from Jakub Jelinek ---
Note that passing the _Bool to varargs function might very well zero extend it
(i.e. mask with 1). As kernel is built with -fno-strict-aliasing, I bet
trying to print *(char *)&tid_agg_rx->removed instead mi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69504
Richard Biener changed:
What|Removed |Added
Keywords||accepts-invalid,
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69494
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69504
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69491
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |6.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69504
--- Comment #3 from Richard Biener ---
I think at some point the FEs created array-refs here. I think I suggested
that elsewhere during last stage1 but nobody implemented that ... (now it's
already again quite late).
Thus for vector[i] create
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69196
--- Comment #12 from Sebastian Huber ---
New numbers for SPARC and PowerPC (rtems4.12-gcc 6.0.0 20160127):
sparc-rtems4.11-gcc -c -O2 -o vprintk.4.11.o vprintk.i
sparc-rtems4.12-gcc -c -O2 -o vprintk.4.12.o vprintk.i
size vprintk.4.11.o
text
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69504
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66655
--- Comment #33 from Nick Clifton ---
The patch did receive approval in the end:
https://gcc.gnu.org/ml/gcc-patches/2016-01/msg02074.html
phew!
As for 68601 - I guess that we can leave it as RESOLVED for now, and see if the
problem resurface
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69447
--- Comment #10 from ktkachov at gcc dot gnu.org ---
(In reply to Richard Henderson from comment #9)
> Created attachment 37484 [details]
> proposed patch
>
> Fixes the test case, in that it prevents the remat.
>
> Starting overnight bootstraps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69511
Bug ID: 69511
Summary: G.gcstack_size uses uintptr instead of size_t
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: go
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69336
--- Comment #12 from Dominik Vogt ---
The test works now on s390x. Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69447
--- Comment #11 from Jakub Jelinek ---
Without knowing the lra-remat code at all, I just wonder if subreg_regs needs
to be one per the whole function, rather than say per extended basic block or
basic block, with the patch any uses in multi-reg s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69408
--- Comment #15 from night_ghost at ykoctpa dot ru ---
steps to repeat:
Arduino recent version should be installed
GCC created by the above script should be in PATH and in Arduino's
/usr/share/arduino/hardware/tools/avr
un-tar testcase, cd to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69462
--- Comment #3 from Dominik Vogt ---
Is this change fit to be posted on gcc-patches? (I have a patch for that
anyway and can post it for you if you like.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69466
--- Comment #7 from Richard Biener ---
I think the fix is wrong, slpeel_duplicate_current_defs_from_edges assumes
from->dest and to->dest are the same (or the same kind of) block. Your
patch merely papers over the issue that one of the exits lea
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69512
Bug ID: 69512
Summary: ICE when using avx with i586
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69512
chrbr at gcc dot gnu.org changed:
What|Removed |Added
Keywords||diagnostic, ice-checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69508
Chris Bainbridge changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69512
Uroš Bizjak changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69488
--- Comment #2 from Rainer Emrich ---
Created attachment 37489
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37489&action=edit
proposed patch
* gnat.dg/sso/*.adb: Robustify dg-output directives.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69488
--- Comment #3 from Rainer Emrich ---
I'm testing the proposed patch on x86_64-w64-mingw32 and
x86_64-unknown-linux-gnu.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69485
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65656
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69462
--- Comment #4 from Jonathan Wakely ---
Yes, but I can't approve changes to that part of GCC and it should probably
wait for stage 1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69466
--- Comment #8 from Richard Biener ---
Ok, it doesn't fix it, it somehow just makes -fno-vect-cost-model necessary.
We still split the edge, but later in vect_loop_versioning then, so the reason
for the bug is still the same - we're looking at f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69512
Uroš Bizjak changed:
What|Removed |Added
Keywords|diagnostic, ice-checking|
Target|i596
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69498
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69488
--- Comment #4 from Eric Botcazou ---
> I'm testing the proposed patch on x86_64-w64-mingw32 and
> x86_64-unknown-linux-gnu.
Thanks. The patch is OK for mainline if the above testing is successful.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69512
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Summ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69454
--- Comment #26 from Ilya Enkovich ---
(In reply to H.J. Lu from comment #25)
> Please add -mpreferred-stack-boundary=2 to your tests. Otherwise,
> you just remove a nop.
Here is a test which crashes LRA with the path you proposed. Crash happe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67364
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69513
Bug ID: 69513
Summary: LTO bootstrap fails with bootstrap-profiled during
linking gnat1 in stagefeedback
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69399
--- Comment #12 from Jakub Jelinek ---
Author: jakub
Date: Wed Jan 27 11:40:04 2016
New Revision: 232869
URL: https://gcc.gnu.org/viewcvs?rev=232869&root=gcc&view=rev
Log:
PR tree-optimization/69399
* wide-int.h (wi::lrshift): Fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69513
--- Comment #1 from Richard Biener ---
This means the DIE in question was created too late or figured unreachable.
case dw_val_class_die_ref:
if (AT_ref_external (a))
...
else
{
gcc_assert (A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68782
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69052
--- Comment #8 from Ilya Enkovich ---
(In reply to amker from comment #7)
> According to discussion at https://gcc.gnu.org/ml/gcc/2016-01/msg00190.html,
> hook is probably not wanted in this case.
> Bernd gave another proposal by moving combine b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69052
--- Comment #9 from amker at gcc dot gnu.org ---
(In reply to Ilya Enkovich from comment #8)
> (In reply to amker from comment #7)
> > According to discussion at https://gcc.gnu.org/ml/gcc/2016-01/msg00190.html,
> > hook is probably not wanted in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69052
--- Comment #10 from Ilya Enkovich ---
(In reply to amker from comment #9)
> I know little about x86, is it because of generation of non-canonical rtl
> expression after this change?
>
> Another question for this case is: Is it because operand o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68730
--- Comment #14 from Bernd Schmidt ---
It does look like an issue with lra-remat...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69052
--- Comment #11 from amker at gcc dot gnu.org ---
(In reply to Ilya Enkovich from comment #10)
> (In reply to amker from comment #9)
> > I know little about x86, is it because of generation of non-canonical rtl
> > expression after this change?
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69454
--- Comment #27 from H.J. Lu ---
(In reply to Ilya Enkovich from comment #26)
> (In reply to H.J. Lu from comment #25)
> > Please add -mpreferred-stack-boundary=2 to your tests. Otherwise,
> > you just remove a nop.
>
> Here is a test which cra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69494
--- Comment #2 from Lukas ---
I was wrong about what part of the standard defines the behavior for volatile
access.
Paragraph 8 of [intro.execution] specifies that access to volatile objects is
observable behavior. Access is defined in [defns.acc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68881
--- Comment #13 from Jakub Jelinek ---
While GCC can do that, what if weakref is used in the source and the definition
is provided by user in inline asm?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69454
--- Comment #28 from Jakub Jelinek ---
(In reply to H.J. Lu from comment #27)
> (In reply to Ilya Enkovich from comment #26)
> > (In reply to H.J. Lu from comment #25)
> > > Please add -mpreferred-stack-boundary=2 to your tests. Otherwise,
> > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69454
--- Comment #29 from H.J. Lu ---
(In reply to Jakub Jelinek from comment #28)
>
> Which will likely penalize even code where the stv pass wouldn't do anything.
In normal case it is a nop since the incoming stack is 128-bit
aligned.
> Isn't it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69245
--- Comment #14 from chrbr at gcc dot gnu.org ---
Author: chrbr
Date: Wed Jan 27 13:03:45 2016
New Revision: 232872
URL: https://gcc.gnu.org/viewcvs?rev=232872&root=gcc&view=rev
Log:
2016-01-20 Christian Bruel
PR target/69245
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69454
--- Comment #30 from H.J. Lu ---
Try this one:
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index a03a515..c82883e 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -3588,16 +3588,6 @@ convert_scalars_to_vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69429
--- Comment #4 from joakim.tjernlund at transmode dot se ---
(In reply to Jakub Jelinek from comment #3)
> Because most of the powerpc distros now use 64KB page size instead of 4KB,
> so having only 4KB common page size means security protection
0x61d029 match_mult_operand
gcc/fortran/matchexp.c:267
$ gfortran --version
GNU Fortran (GCC) 6.0.0 20160127 (experimental)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69245
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69429
--- Comment #5 from Jakub Jelinek ---
Of course even for ppc32. The ppc64 kernel supports ppc32 binaries.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69454
--- Comment #31 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #28)
> Which will likely penalize even code where the stv pass wouldn't do anything.
> Isn't it better to just disable the stv pass if the stack isn't aligned
> enough
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69462
Dominik Vogt changed:
What|Removed |Added
Summary|stack overflow detected |FLT_EVAL_METHOD and
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60336
--- Comment #45 from H.J. Lu ---
I opened a clang bug:
https://llvm.org/bugs/show_bug.cgi?id=26337
I propose the following definitions:
i. An empty record is:
1. A class without member. Or
2. An array of empty records. Or
3. A class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69295
--- Comment #9 from Jonathan Wakely ---
On big-endian ppc64 ext/special_functions/hyperg/check_value.cc these tests
fail:
data167, toler167 on line 11579 max_abs_frac = 4.82864e-13
data171, toler171 on line 11579 max_abs_frac = 5.15741e-12
dat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68662
--- Comment #7 from Jakub Jelinek ---
Seems like powerpc* has lots of other issues related to mixing pic and non-pic
code. E.g.
int x;
int
foo (void)
{
return x;
}
__attribute__((optimize ("PIC"))) int
bar (void)
{
return x;
}
seems to IC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69454
--- Comment #32 from Ilya Enkovich ---
(In reply to Uroš Bizjak from comment #31)
> Maybe we can use HJ's patch from Comment #27 and communicate converted_insns
> flag from convert_scalars_to_vector to ix86_finalize_stack_realign_flags?
> The i_f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68881
--- Comment #14 from H.J. Lu ---
(In reply to Jakub Jelinek from comment #13)
> While GCC can do that, what if weakref is used in the source and the
> definition is provided by user in inline asm?
The assembly manual says:
7.102 '.weakref ALIAS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69515
Bug ID: 69515
Summary: partial specialization of variable templates is broken
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69295
--- Comment #10 from Jakub Jelinek ---
Does -ffloat-store help on ppc64 though? I believe that target doesn't have
excess precision... Perhaps fma is used somewhere (can you objdump -dr
check_value.exe | grep madd ?)? No idea if it is possible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69454
--- Comment #33 from H.J. Lu ---
(In reply to Ilya Enkovich from comment #32)
> (In reply to Uroš Bizjak from comment #31)
> > Maybe we can use HJ's patch from Comment #27 and communicate converted_insns
> > flag from convert_scalars_to_vector to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69295
--- Comment #11 from Jonathan Wakely ---
(In reply to Jakub Jelinek from comment #10)
> Does -ffloat-store help on ppc64 though? I believe that target doesn't have
> excess precision... Perhaps fma is used somewhere (can you objdump -dr
> check_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67364
--- Comment #4 from Marek Polacek ---
Is there any practical difference between brace-init-list:
constexpr closure() : member{} { }
and expression-list:
constexpr closure() : member() { }
?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69496
--- Comment #6 from Marek Polacek ---
Author: mpolacek
Date: Wed Jan 27 14:26:38 2016
New Revision: 232875
URL: https://gcc.gnu.org/viewcvs?rev=232875&root=gcc&view=rev
Log:
PR c++/69496
* constexpr.c (cxx_eval_array_reference):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69496
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68273
Bernd Schmidt changed:
What|Removed |Added
CC||bernds at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69450
Jakub Jelinek changed:
What|Removed |Added
Priority|P1 |P4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69032
--- Comment #2 from Andrey Belevantsev ---
Created attachment 37490
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37490&action=edit
proposed patch
We fail to find the proper seqno for the fresh bookkeeping copy here. The
problem is that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69268
--- Comment #4 from vehre at gcc dot gnu.org ---
Author: vehre
Date: Wed Jan 27 14:48:04 2016
New Revision: 232876
URL: https://gcc.gnu.org/viewcvs?rev=232876&root=gcc&view=rev
Log:
gcc/testsuite/ChangeLog:
2016-01-27 Andre Vehreschild
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69355
--- Comment #21 from Martin Jambor ---
Author: jamborm
Date: Wed Jan 27 14:51:17 2016
New Revision: 232877
URL: https://gcc.gnu.org/viewcvs?rev=232877&root=gcc&view=rev
Log:
[PR 69355] Correct hole detection when total_scalarization fails
2016-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69166
--- Comment #8 from Richard Biener ---
Author: rguenth
Date: Wed Jan 27 14:54:03 2016
New Revision: 232878
URL: https://gcc.gnu.org/viewcvs?rev=232878&root=gcc&view=rev
Log:
2016-01-27 Richard Biener
PR tree-optimization/69166
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69166
Richard Biener changed:
What|Removed |Added
Known to work||6.0
Summary|[4.9/5/6 Regress
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68662
--- Comment #8 from Peter Bergner ---
(In reply to Jakub Jelinek from comment #7)
> seems to ICE due to endless recursion with -O2 -m32 (every force_reg causes
> another force_reg, at least in x86_64-linux -> powerpc64-linux cross).
I see a simi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69268
vehre at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69495
--- Comment #3 from janus at gcc dot gnu.org ---
(In reply to Manuel López-Ibáñez from comment #2)
> I think there must be a lot more cases of this:
Yes, those should be taken care of as well. I'll try to do that.
I guess practically all occurre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69495
--- Comment #4 from janus at gcc dot gnu.org ---
Btw, I noticed another loosely related issue concerning misspellings of the
warning flags:
$ gfortran -Wunused-labels test.f90
gfortran: error: unrecognized command line option ‘-Wunused-labels’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69295
--- Comment #12 from Jonathan Wakely ---
Author: redi
Date: Wed Jan 27 15:09:38 2016
New Revision: 232879
URL: https://gcc.gnu.org/viewcvs?rev=232879&root=gcc&view=rev
Log:
Set FP options for failing special functions tests
PR libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69295
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69495
--- Comment #5 from Manuel López-Ibáñez ---
(In reply to janus from comment #4)
> This seems very inconsistent: All three calls involve an invalid flag, but
> the diagnostics is very different for each of them (it's particularly bad
> that the se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69485
--- Comment #5 from janus at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #4)
> Confirmed from 4.8 up to trunk (6.0) for fixed-form.
>
> After converting the include file to free-form I get
So you're saying the problem onl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69495
--- Comment #6 from Manuel López-Ibáñez ---
(In reply to janus from comment #3)
> I guess practically all occurrences of "gfc_warning (0, ..." need to be
> transformed, or are there cases where the zero is legitimate?
Most warnings don't have a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69466
--- Comment #9 from Richard Biener ---
I am testing that patch now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69495
--- Comment #7 from janus at gcc dot gnu.org ---
(In reply to Manuel López-Ibáñez from comment #5)
> (In reply to janus from comment #4)
> > Is there a reason for this behavior?
>
> https://gcc.gnu.org/wiki/FAQ#wnowarning
I see. So this is inten
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69484
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P4
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68514
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65931
Jakub Jelinek changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66487
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69317
--- Comment #3 from Martin Sebor ---
Author: msebor
Date: Wed Jan 27 15:44:07 2016
New Revision: 232881
URL: https://gcc.gnu.org/viewcvs?rev=232881&root=gcc&view=rev
Log:
PR c++/69317 - [6 regression] wrong ABI version in -Wabi warnings
gcc/cp/
1 - 100 of 233 matches
Mail list logo
