https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78875
Bug ID: 78875
Summary: -fstack-protector on powerpc64 now always use TLS,
won't work for kernel/firmware
Product: gcc
Version: 6.2.0
Status: UNCONFIRMED
Severit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78749
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78767
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78516
--- Comment #21 from Peter Bergner ---
(In reply to Peter Bergner from comment #20)
> Vlad, for the following change in the hunk above:
>
> > new_reg != NULL_RTX ? sreg : src,
>
> shouldn't that always be j
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78874
Bug ID: 78874
Summary: Manual describes "-Wno-aggressive-loop-optimizations"
as if without "no-"
Product: gcc
Version: 6.2.1
Status: UNCONFIRMED
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77767
--- Comment #8 from Jakub Jelinek ---
Author: jakub
Date: Wed Dec 21 00:07:49 2016
New Revision: 243832
URL: https://gcc.gnu.org/viewcvs?rev=243832&root=gcc&view=rev
Log:
PR c/77767
* c-decl.c (grokdeclarator): If *expr is non-NU
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78516
--- Comment #20 from Peter Bergner ---
(In reply to Peter Bergner from comment #19)
> emit_insn (GEN_FCN (sri.icode) (new_reg != NULL_RTX ? new_reg : dest,
> new_reg != NULL_RTX ? sreg : src,
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78873
Bug ID: 78873
Summary: Virtual call after conversion to base class pointer is
not devirtualized
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71444
--- Comment #2 from Jonathan Wakely ---
In fact it looks like the patch should work for mingw-w64 v4, and maybe v3 too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78870
--- Comment #3 from Jonathan Wakely ---
(In reply to Jan Niklas Hasse from comment #2)
> I'm willing to help.
Great! Please read
https://gcc.gnu.org/onlinedocs/libstdc++/manual/appendix_contributing.html
especially the part about legal paperwork
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78842
Jonathan Wakely changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78872
Jonathan Wakely changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78516
--- Comment #19 from Peter Bergner ---
(In reply to Peter Bergner from comment #18)
> With the patch Vlad attached minus the one unwanted line/typo, I'm getting
> an ICE on a powerpc64le-linux bootstrap. Looking into it.
Here's a minimal test c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78842
--- Comment #6 from Jim Michaels ---
(In reply to Nathan Sidwell from comment #4)
> sigh, bugzilla's moving on to 'random' other bug gets me. Again.
btw, I think that random bug number feature is in preferences.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78842
--- Comment #5 from Jim Michaels ---
I am going to have to go digging through my code. the function that I had this
error on about icase shadowing a parameter was a global var, and I tried
#include
#include
#include
bool icase=false;
std::vect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78872
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52192
--- Comment #5 from Jonathan Wakely ---
Should we change the target to *-*-netbsd* now that solaris 8 and 9 are not
supported?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78872
--- Comment #1 from Jim Michaels ---
icompare.cpp:12:119: error: no 'int std::locale::icompare(const char_type*,
const char_type*, const char_type*, const char_type*) const' member function
declared in class 'std::locale'
int locale::icompar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78872
Bug ID: 78872
Summary: g++ refuses const trailing a function declaration.
Product: gcc
Version: 6.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78516
--- Comment #18 from Peter Bergner ---
With the patch Vlad attached minus the one unwanted line/typo, I'm getting an
ICE on a powerpc64le-linux bootstrap. Looking into it.
/home/bergner/gcc/gcc-fsf-mainline-pr78516/libgcc/libgcc2.c: In function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70568
Michael Meissner changed:
What|Removed |Added
Known to work||4.8.5
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78823
Michael Meissner changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70568
--- Comment #6 from Michael Meissner ---
*** Bug 78823 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77767
--- Comment #7 from Jakub Jelinek ---
Unfortunately that version breaks the pr49120.c testcase, because mark_exp_read
doesn't deal with STATEMENT_LISTs. I'll test the other patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77754
--- Comment #8 from joseph at codesourcery dot com ---
On Tue, 20 Dec 2016, jakub at gcc dot gnu.org wrote:
> So, where would be the best place to remove the VLA bounds from parameters of
> fn declarations? Some function called from c_write_glo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77767
--- Comment #6 from joseph at codesourcery dot com ---
I think the append_to_statement_list version should be preferred.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78871
Martin Liška changed:
What|Removed |Added
Keywords||ice-on-valid-code
Status|UNCO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78516
--- Comment #17 from joseph at codesourcery dot com ---
On Tue, 20 Dec 2016, bergner at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78516
>
> --- Comment #16 from Peter Bergner ---
> (In reply to Vladimir Makarov from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78871
Bug ID: 78871
Summary: Anonymous namespace and -flto -gsplit-dwarf: ICE in
lhd_decl_printable_name, at langhooks.c:215
Product: gcc
Version: 7.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78808
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78839
--- Comment #10 from Tom O'Connor ---
In regards to GDB, I noticed that when using a macro to get the offset for
these bitfields, with objects built by both GCC 5 and earlier as well as GCC 6,
I always get 0. For example:
(gdb) macro define off
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72764
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78751
--- Comment #3 from Segher Boessenkool ---
Created attachment 40383
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40383&action=edit
patch
I use this patch as workaround. It, well, sucks. But it does work.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78660
--- Comment #5 from Paul Hua ---
(In reply to Paul Hua from comment #4)
>
> Maybe the r242326 cause the bug, the r242324 build success.
>
The r242326 and r242324 has another bug that r242522 fixed. If use r242326 to
reproduce this bug, you shou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71563
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78861
--- Comment #6 from mgansser at alice dot de
---
(In reply to Markus Trippelsdorf from comment #5)
> (In reply to Jonathan Wakely from comment #4)
> > No, that will convert the stream to a bool then try to bitshift it.
> >
> > It should be:
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71724
Bernd Schmidt changed:
What|Removed |Added
CC||bernds at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78861
--- Comment #5 from Markus Trippelsdorf ---
(In reply to Jonathan Wakely from comment #4)
> No, that will convert the stream to a bool then try to bitshift it.
>
> It should be:
>
>result = bool( iss >> t.duration >> t.width );
Yeah, sorry
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78861
--- Comment #4 from Jonathan Wakely ---
No, that will convert the stream to a bool then try to bitshift it.
It should be:
result = bool( iss >> t.duration >> t.width );
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78863
--- Comment #3 from Martin Liška ---
Created attachment 40381
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40381&action=edit
Untested patch
Hello,
I am using BIT Fields in my program with powerPC target and when I am trying
check stack usage I see some strange values for the stack pointer.
typedef struct sample_type{
unsigned int var1 : 2;
unsigned int var2 : 2;
unsigned int var3 : 2;
unsigned int var4 : 2;
unsigned int var5 : 2;
un
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78861
--- Comment #3 from Markus Trippelsdorf ---
(In reply to mgans...@alice.de from comment #2)
> (In reply to Markus Trippelsdorf from comment #1)
> > https://gcc.gnu.org/gcc-6/porting_to.html
>
> I am not a software developer, could you please tel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78861
--- Comment #2 from mgansser at alice dot de
---
(In reply to Markus Trippelsdorf from comment #1)
> https://gcc.gnu.org/gcc-6/porting_to.html
I am not a software developer, could you please tell me, where can i get help ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72707
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71827
--- Comment #5 from Jakub Jelinek ---
__INTPTR_TYPE__
foo ()
{
m: n: constexpr __INTPTR_TYPE__ a = ((__INTPTR_TYPE__) &&n -
(__INTPTR_TYPE__) &&m) + 23;
return a;
}
compiles fine, so it is considered an integral constant expression that jus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78660
--- Comment #4 from Paul Hua ---
The r243817 still build failure.
configure:3460: /home/xuchenghua/GCC/test/gcc-r243817_obj/./gcc/xgcc
-B/home/xuchenghua/GCC/test/gcc-r2438
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78847
--- Comment #5 from Richard Biener ---
Actually disabling reassoc is enough to "fix" it, the patch itself is not
needed,
fixed by VRP then (which also folds stmts and knows the &MEM trick).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71821
--- Comment #3 from Jakub Jelinek ---
TEMPLATE_ID_EXPR is considered to be potential_constant_expression_1, so
require_potential_rvalue_constant_expression (e)
at the start of cxx_alignas_expr. But cxx_eval_constant_expression does not
handle it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78839
Pierre-Marie de Rodat changed:
What|Removed |Added
CC||derodat at adacore dot com
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78840
--- Comment #2 from Nathan Sidwell ---
Created attachment 40379
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40379&action=edit
reduced testcase.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78842
--- Comment #4 from Nathan Sidwell ---
sigh, bugzilla's moving on to 'random' other bug gets me. Again.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77754
--- Comment #7 from Jakub Jelinek ---
So, where would be the best place to remove the VLA bounds from parameters of
fn declarations? Some function called from c_write_global_declarations_1 and
from walking BLOCK tree vars e.g. right before calli
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77754
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78870
--- Comment #2 from Jan Niklas Hasse ---
I'm willing to help. Is there an existing starting point for Windows? Can
boost::filesystem's implementation be used?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78792
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78870
--- Comment #1 from Jonathan Wakely ---
Because nobody who uses Windows has contributed any help to make it work.
Nothing will change until somebody does that. I've written 100% of the
filesystem code so far, but I'm not going to do the Windows i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77812
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15826
Matthew Fortune changed:
What|Removed |Added
CC||matthew.fortune at imgtec dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77767
--- Comment #5 from Jakub Jelinek ---
Created attachment 40378
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40378&action=edit
gcc7-pr77767-2.patch
Version with append_to_statement_list.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78863
Martin Liška changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot
gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77767
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78847
--- Comment #4 from Richard Biener ---
Note that the attached patch will actually end up propagating that &MEM form
everywhere (and run into those object-size fallout issues).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78863
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78869
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78869
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78835
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78835
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|nathan at g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78851
--- Comment #8 from Marc Glisse ---
(In reply to Richard Biener from comment #7)
> I don't think that the middle-end converts pow(, int-valued) to powi anywhere
> as generally the result can be off too far (maybe we could for some known
> special
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78847
--- Comment #3 from Richard Biener ---
Created attachment 40376
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40376&action=edit
forwprop fix
The forwprop piece, untested (apart from on the testcase). No time to explore
further before the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78847
--- Comment #2 from Richard Biener ---
(In reply to Marc Glisse from comment #1)
> Not sure what the best angle is here.
>
> _18 = (unsigned long) &MEM[(void *)&foo + 9B];
> _16 = _18 + 1;
>
> looks like it would be better as:
>
> _19 = (unsig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71473
Jakub Jelinek changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78851
--- Comment #7 from Richard Biener ---
Note that absence of flags such as -ffast-math only libstdc++ knows whether
the standard allows pow(, int) to be implemented with more than a single
rounding.
I don't think that the middle-end converts pow(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78694
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78870
Bug ID: 78870
Summary: Support std::filesystem on Windows
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78660
--- Comment #3 from Matthew Fortune ---
(In reply to Aldy Hernandez from comment #2)
> I can't reproduce on a cross build. Is there a mips64el box on the compile
> farm or somewhere public so someone can look at this?
The following machines wer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78694
--- Comment #17 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Tue Dec 20 09:39:44 2016
New Revision: 243820
URL: https://gcc.gnu.org/viewcvs?rev=243820&root=gcc&view=rev
Log:
[ARM] PR target/78694: Avoid invalid RTL sharing in minip
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78869
Bug ID: 78869
Summary: Strange __builtin_memcpy optimisations
Product: gcc
Version: 6.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78852
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78859
Richard Biener changed:
What|Removed |Added
Keywords||build, diagnostic
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78867
--- Comment #5 from Richard Biener ---
The issue is that at read-in cfun is unexpectedly NULL. We're here:
static void
input_function (tree fn_decl, struct data_in *data_in,
struct lto_input_block *ib, struct lto_input_block *ib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78867
--- Comment #4 from Dominique d'Humieres ---
> Uh, my bisection failed, as it turns out r243624 fails for me..
Looking more carefully r238055 is OK, but r238821 is not.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78572
Aldy Hernandez changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org
Assi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78867
--- Comment #3 from Janne Blomqvist ---
(In reply to Janne Blomqvist from comment #2)
> (In reply to Dominique d'Humieres from comment #1)
> > This seems to be a regression between revisions r243624 (2016-12-13,
> > compiles) and r243765 (2016-12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71232
Eric Botcazou changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71232
--- Comment #4 from Eric Botcazou ---
Author: ebotcazou
Date: Tue Dec 20 08:50:21 2016
New Revision: 243819
URL: https://gcc.gnu.org/viewcvs?rev=243819&root=gcc&view=rev
Log:
Fix PR testsuite/71232 entry.
Modified:
trunk/gcc/testsuite/Chang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71237
--- Comment #6 from Eric Botcazou ---
Author: ebotcazou
Date: Tue Dec 20 08:45:52 2016
New Revision: 243818
URL: https://gcc.gnu.org/viewcvs?rev=243818&root=gcc&view=rev
Log:
PR testsuite/71237
* gnat.dg/vect1.adb: Add -fno-vect-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71473
--- Comment #8 from Jakub Jelinek ---
Reduced testcase:
void
foo (double *a, double *b, double *c, int m, int o, int p)
{
_Cilk_for (int i = 0; i < p; ++i)
a[i] += __sec_reduce_add (b[i:o] * c[m:o:-1]);
}
ICEs with both C and C++.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71232
Eric Botcazou changed:
What|Removed |Added
Component|middle-end |testsuite
--- Comment #3 from Eric Botca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78660
Aldy Hernandez changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78660
Aldy Hernandez changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org,
90 matches
Mail list logo
