https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90334
--- Comment #7 from Shakthi Kannan ---
Created attachment 46559
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46559=edit
Use whitespace between sourceware.org and gcc.gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91091
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89976
--- Comment #2 from Nikita Kniazev ---
The same warning as when the object is constructed inside the main function:
int main()
{
XorYorZ x;
return x.x;
}
Also, the warning is not triggered in C++17+ mode with:
XorYorZ foo()
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91053
--- Comment #2 from Orion Hodson ---
For sure the goal wasn't to suggest that this was due to a privileged
operation.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91096
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90712
--- Comment #1 from Sam Tebbs ---
Author: samtebbs
Date: Fri Jul 5 13:16:55 2019
New Revision: 273138
URL: https://gcc.gnu.org/viewcvs?rev=273138=gcc=rev
Log:
[PATCH][GCC][AARCH64] PR target/90712 Fix gcc.dg/rtl/aarch64/subs_adds_sp.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83374
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91095
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91092
--- Comment #2 from Florian Weimer ---
Current util-linux is an example:
$ ./configure
[…]
checking wchar_t support... yes
[…]
$ ./configure CC="gcc -Werror=implicit-function-declaration"
[…]
configure: WARNING: wchar_t support not found; not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91096
Bug ID: 91096
Summary: Openmp vector max reduction incorrect
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91092
--- Comment #5 from Jonathan Wakely ---
Would an ugly but pragmatic approach be possible? e.g. if the first line of the
translation unit is "/* confdefs.h */ then assume GCC is being invoked by
configure, and only warn instead of giving an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83374
--- Comment #7 from Marek Polacek ---
Related PRs:
PR91079
PR91080
PR91081
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91092
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91096
--- Comment #2 from Jakub Jelinek ---
Created attachment 46561
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46561=edit
gcc10-pr91096.patch
Does this fix it for you? Works for me with:
make check-gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91092
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91096
--- Comment #4 from Jakub Jelinek ---
(In reply to Wilco from comment #3)
> But why does it always add a redundant test with FLT_MAX in the loop?
Which loop do you mean? If the vectorized one, OpenMP has rules on what needs
to be done, at the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83374
--- Comment #5 from Marek Polacek ---
Author: mpolacek
Date: Fri Jul 5 14:45:30 2019
New Revision: 273139
URL: https://gcc.gnu.org/viewcvs?rev=273139=gcc=rev
Log:
DR 1813
PR c++/83374 - __is_standard_layout wrong for a class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91096
--- Comment #3 from Wilco ---
(In reply to Jakub Jelinek from comment #2)
> Created attachment 46561 [details]
> gcc10-pr91096.patch
>
> Does this fix it for you? Works for me with:
> make check-gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91092
--- Comment #4 from Jonathan Wakely ---
And it doesn't help all the existing configure scripts, that won't get
regenerated even if a new autoconf is released.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91094
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91091
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91091
--- Comment #4 from Richard Biener ---
Author: rguenth
Date: Fri Jul 5 12:50:45 2019
New Revision: 273135
URL: https://gcc.gnu.org/viewcvs?rev=273135=gcc=rev
Log:
2019-07-05 Richard Biener
PR tree-optimization/91091
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #41 from The Written Word
---
(In reply to The Written Word from comment #39)
> (In reply to EML from comment #25)
> > I have applied the patch and tried your other suggestions, still the stage1
> > compiler has the same problems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78884
--- Comment #10 from Jens Wellner ---
I have tested the trunk and it is working as expected.
Thanks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #43 from The Written Word
---
(In reply to dave.anglin from comment #42)
> On 2019-07-05 12:57 a.m., bugzilla-gcc at thewrittenword dot com wrote:
> > I can now duplicate what you're seeing:
> > $ diff -u gcc-4.9.4/hello.s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91092
Bug ID: 91092
Summary: Error on implicit function declarations by default
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91093
Bug ID: 91093
Summary: Error on implicit int by default
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91090
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90883
Wilco changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #42 from dave.anglin at bell dot net ---
On 2019-07-05 12:57 a.m., bugzilla-gcc at thewrittenword dot com wrote:
> I can now duplicate what you're seeing:
> $ diff -u gcc-4.9.4/hello.s gcc-8.3.0/hello.s
> --- gcc-4.9.3/hello.s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91060
--- Comment #4 from Christophe Lyon ---
Unfortunately, it's still failing as of r273133.
It fails at the very first check:
v1 = 2 + v0; check (short, 8, v0, v1, 2, +, l);
The generated code for main is:
main:
@ args = 0, pretend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #40 from The Written Word
---
Created attachment 46560
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46560=edit
Revert PR60465
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91094
Bug ID: 91094
Summary: BB vectorization is too quick to disable itself
because of possible unrolling needed
Product: gcc
Version: 10.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90334
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91091
--- Comment #2 from Richard Biener ---
Author: rguenth
Date: Fri Jul 5 12:48:42 2019
New Revision: 273134
URL: https://gcc.gnu.org/viewcvs?rev=273134=gcc=rev
Log:
2019-07-05 Richard Biener
PR tree-optimization/91091
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91095
Bug ID: 91095
Summary: internal compiler error: in tsubst_copy
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #44 from EML ---
The aforementioned gprel patch I think is incorrect on HPUX, given this in
ia64.c
/* For HPUX, it is illegal to have relocations in shared segments. */
static int
ia64_hpux_reloc_rw_mask (void)
{
return 3;
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #45 from dave.anglin at bell dot net ---
On 2019-07-05 3:34 p.m., elowe at elowe dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
>
> --- Comment #44 from EML ---
> The aforementioned gprel patch I think is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91092
--- Comment #6 from Jonathan Wakely ---
But don't do that if -Werror=implicit-function-declaration was used explicitly,
because maybe the configure test is actually trying to detect that error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91092
--- Comment #9 from Florian Weimer ---
(In reply to Andreas Schwab from comment #8)
> What about cmake, metaconfig, meson, scons, ...
I hope that the more modern things get this correct and encourage more
high-level checks.
I plan to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67184
--- Comment #17 from paolo at gcc dot gnu.org ---
Author: paolo
Date: Fri Jul 5 18:03:05 2019
New Revision: 273147
URL: https://gcc.gnu.org/viewcvs?rev=273147=gcc=rev
Log:
/cp
2019-07-05 Paolo Carlini
PR c++/67184 (again)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67184
Paolo Carlini changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69445
--- Comment #7 from paolo at gcc dot gnu.org ---
Author: paolo
Date: Fri Jul 5 18:03:05 2019
New Revision: 273147
URL: https://gcc.gnu.org/viewcvs?rev=273147=gcc=rev
Log:
/cp
2019-07-05 Paolo Carlini
PR c++/67184 (again)
PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91097
Bug ID: 91097
Summary: [10 regression] many ICEs starting with r273131
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91077
--- Comment #7 from Paul Thomas ---
(In reply to ygal klein from comment #4)
> The following code presents a difference (!) between gfortran 8.2 and
> gfortran 9.1:
>
> program test
> implicit none
> integer, parameter :: length = 2
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91098
Bug ID: 91098
Summary: [10 Regression] internal compiler error: tree check:
expected var_decl or field_decl or function_decl or
type_decl or template_decl, have using_decl in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91061
Iain Buclaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90893
Iain Buclaw changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #49 from The Written Word
---
Created attachment 46565
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46565=edit
hello.c compiled with -da
/opt/build/china/gcc-8.3.0/.obj-/./gcc/xgcc
-B/opt/build/china/gcc-8.3.0/.obj-/./gcc/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #48 from The Written Word
---
Created attachment 46564
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46564=edit
hello.s assembly output of hello.c
/opt/build/china/gcc-8.3.0/.obj-/./gcc/xgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91092
--- Comment #7 from Florian Weimer ---
(In reply to Jonathan Wakely from comment #5)
> Would an ugly but pragmatic approach be possible? e.g. if the first line of
> the translation unit is "/* confdefs.h */ then assume GCC is being invoked
> by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91092
--- Comment #8 from Andreas Schwab ---
What about cmake, metaconfig, meson, scons, ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91077
--- Comment #6 from Paul Thomas ---
Created attachment 46562
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46562=edit
Patch for the PR
This fixes the original problem and regtests OK.
I need to think this through and to test it against
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91097
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
URL|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #47 from The Written Word
---
Created attachment 46563
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46563=edit
Hello.c test program
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #46 from The Written Word
---
(In reply to dave.anglin from comment #45)
>
> You could dump the RTL by adding "-da" to the compile options. Then, you
> could upload the "final" file.
I am uploading hello.c, hello.s, and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44032
--- Comment #7 from Eric Gallager ---
Richard says the FSF doesn't object to combinations of GFDL code from the
manual with GPL code from the source and that we can put a statement to this
effect in the internals manual.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #50 from dave.anglin at bell dot net ---
On 2019-07-05 4:28 p.m., bugzilla-gcc at thewrittenword dot com wrote:
> I am uploading hello.c, hello.s, and hello.c.313r.dfinish.
I'm still puzzled why .LC0 ends up in .rodata.
(insn 30 2 34
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #51 from The Written Word
---
(In reply to dave.anglin from comment #50)
> On 2019-07-05 4:28 p.m., bugzilla-gcc at thewrittenword dot com wrote:
> > I am uploading hello.c, hello.s, and hello.c.313r.dfinish.
> I'm still puzzled why
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90813
Pat Haugen changed:
What|Removed |Added
CC||pthaugen at linux dot ibm.com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #55 from EML ---
Doing some more testing on my "gprel unfixed fix" 32-bit gcc, I found out that
it seems to be missing the 32-bit pointer swizzling needed to make 32bit
executables on 64-bit IA-64. The test program assembler is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67184
--- Comment #19 from Jakub Jelinek ---
Author: jakub
Date: Fri Jul 5 20:51:44 2019
New Revision: 273149
URL: https://gcc.gnu.org/viewcvs?rev=273149=gcc=rev
Log:
PR c++/67184
PR c++/69445
* call.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69445
--- Comment #8 from Jakub Jelinek ---
Author: jakub
Date: Fri Jul 5 20:51:44 2019
New Revision: 273149
URL: https://gcc.gnu.org/viewcvs?rev=273149=gcc=rev
Log:
PR c++/67184
PR c++/69445
* call.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70769
fourmisain+gcc at gmail dot com changed:
What|Removed |Added
Version|5.2.0 |9.1.0
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #52 from EML ---
Note, regardless of reverting the gprel patch, GCC 8 puts the data in .rodata.
However, doesn't gcc 4.9.x do the same thing, it just moves it to GOT with
ltoffx?
.file "foo.c"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #53 from The Written Word
---
(In reply to EML from comment #52)
> Note, regardless of reverting the gprel patch, GCC 8 puts the data in
> .rodata.
>
> However, doesn't gcc 4.9.x do the same thing, it just moves it to GOT with
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #54 from The Written Word
---
(In reply to EML from comment #52)
> objdump -h -s foo
> Contents of section .rodata:
> 40007f8 48656c6c 6f732057 6f726c64 00Hellos World.
>
>
> So gcc 4.9.x also puts the string into
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86418
--- Comment #5 from Eric Gallager ---
(In reply to Martin Sebor from comment #4)
> Confirmed. My preference would be to resolve pr82922 and diagnose all calls
> to functions without a prototype.
Agreed.
> Short of that, this could be handled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82922
--- Comment #8 from Eric Gallager ---
(In reply to Martin Sebor from comment #7)
> I posted a GCC 9 patch here:
> https://gcc.gnu.org/ml/gcc-patches/2018-06/msg00675.html
>
> It adds -Wstrict-prototypes to -Wall. Unfortunately, it got
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90581
Eric Gallager changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
70 matches
Mail list logo
