https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84931
--- Comment #5 from Thomas Koenig ---
Author: tkoenig
Date: Mon Mar 19 07:04:35 2018
New Revision: 258641
URL: https://gcc.gnu.org/viewcvs?rev=258641&root=gcc&view=rev
Log:
2018-03-19 Thomas Koenig
PR fortran/84931
* simplify
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84938
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84939
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84939
Marek Polacek changed:
What|Removed |Added
Target Milestone|--- |6.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84939
--- Comment #2 from Marek Polacek ---
G++ 4.9 says:
84939.C:8:46: warning: taking sizeof array of runtime bound [-Wvla]
a() { (sizeof(char[static_cast(d)])); }
^
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71485
Marek Polacek changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84944
Bug ID: 84944
Summary: UBSAN: gcc/optabs.c:6550:26: runtime error: load of
value 131075, which is not a valid value for type
'memmodel'
Product: gcc
Version: unkn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84940
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84944
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84643
--- Comment #1 from Martin Liška ---
*** Bug 84944 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84643
--- Comment #2 from Martin Liška ---
It's caused by fact that
#define IX86_HLE_ACQUIRE (1 << 16)
#define IX86_HLE_RELEASE (1 << 17)
are not defined in memmodel enum.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84940
--- Comment #2 from Marek Polacek ---
r239267
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84941
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84945
Bug ID: 84945
Summary: UBSAN: gcc/config/i386/i386.c:33312:22: runtime error:
shift exponent 32 is too large for 32-bit type 'int'
Product: gcc
Version: unknown
Status: U
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84942
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84943
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84946
Bug ID: 84946
Summary: UBSAN: in mem_valid_for_store_merging
../../gcc/gimple-ssa-store-merging.c:3951
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84946
Martin Liška changed:
What|Removed |Added
Last reconfirmed||2018-3-19
Blocks|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84811
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84937
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84937
--- Comment #1 from Marek Polacek ---
r240756
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84947
Bug ID: 84947
Summary: UBSAN:
ipcp_bits_lattice::meet_with(generic_wide_int >,
generic_wide_int >,
unsigned int) ../../gcc/ipa-cp.c:1058
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84946
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84936
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84901
Richard Biener changed:
What|Removed |Added
Keywords||lto
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84899
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84900
Richard Biener changed:
What|Removed |Added
Keywords||accepts-invalid
--- Comment #1 from Ric
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84936
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84906
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |8.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84908
Richard Biener changed:
What|Removed |Added
Target||x86_64-*-*, i?86-*-*
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84711
--- Comment #9 from Tamar Christina ---
Hi Christophhe,
This seems to be a combine issue.
It thinks that
(set (reg/i:SF 16 s0)
(vec_select:SF (reg:V4SF 16 s0 [ xD.6085 ])
(parallel [
(const_int 0 [0])
])
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84947
Martin Liška changed:
What|Removed |Added
Last reconfirmed||2018-3-19
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84927
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84919
Richard Biener changed:
What|Removed |Added
Keywords||diagnostic
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84925
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84945
Martin Liška changed:
What|Removed |Added
Last reconfirmed||2018-3-19
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84929
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84927
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84900
--- Comment #2 from wierton <141242068 at smail dot nju.edu.cn> ---
(In reply to Richard Biener from comment #1)
> I belive the code is invalid and using literal 0 instead of test = 0
> shouldn't make it accepted either. clang rejects both varian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84935
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84936
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84945
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
Last reconfirmed|2018-03-19 00:00:0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84937
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84940
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84943
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84938
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84942
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84945
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84939
Richard Biener changed:
What|Removed |Added
Keywords||error-recovery
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84946
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
Version|unknown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84615
--- Comment #11 from Janne Blomqvist ---
Yes, makes sense. And the same happens if one uses an external function with a
hand-rolled interface declaration:
function chararray2string(chararray) result(text)
character(len=1), dimension(:) :: char
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84615
--- Comment #12 from Janne Blomqvist ---
So to be clear, the problem seems to be that while the code generation for the
function itself appears Ok, it generates the interface wrong (i.e. uses the
declared charlen kind instead of C_SIZE_T), and th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84711
--- Comment #10 from Tamar Christina ---
Author: tnfchris
Date: Mon Mar 19 09:14:25 2018
New Revision: 258642
URL: https://gcc.gnu.org/viewcvs?rev=258642&root=gcc&view=rev
Log:
gcc/
2018-03-19 Tamar Christina
PR target/84711
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84945
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84643
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84948
Bug ID: 84948
Summary: [8 regression] ICE in set_from, at
go/gofrontend/types.cc:2660
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84948
Andreas Schwab changed:
What|Removed |Added
Target Milestone|--- |8.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84942
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84615
--- Comment #13 from Thomas Koenig ---
(In reply to Janne Blomqvist from comment #12)
> So to be clear, the problem seems to be that while the code generation for
> the function itself appears Ok, it generates the interface wrong (i.e. uses
> the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84941
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Compon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84615
--- Comment #14 from Janne Blomqvist ---
(In reply to Thomas Koenig from comment #13)
> (In reply to Janne Blomqvist from comment #12)
> > So to be clear, the problem seems to be that while the code generation for
> > the function itself appears
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84945
Julia Koval changed:
What|Removed |Added
CC||julia.koval at intel dot com
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84945
--- Comment #4 from Jakub Jelinek ---
See above, that is an ABI change on all of x86.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84932
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426
Bug 63426 depends on bug 84932, which changed state.
Bug 84932 Summary: [8 Regression] i386/cpuinfo.h:293: 4 * bad bitshifts ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84932
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84945
Jakub Jelinek changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84941
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84933
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Version|unknown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84947
Richard Biener changed:
What|Removed |Added
Version|unknown |8.0.1
Target Milestone|8.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84949
Bug ID: 84949
Summary: -ffast-math bugged with respect to NaNs
Product: gcc
Version: 5.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84949
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84942
--- Comment #3 from Jakub Jelinek ---
Created attachment 43700
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43700&action=edit
gcc8-pr84942.patch
Full untested patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84891
Richard Biener changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84940
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84940
--- Comment #4 from Jakub Jelinek ---
Slightly adjusted testcase:
void
foo (int x)
{
struct {} a[1][x](-a[0]); // { dg-error "wrong type argument to unary minus"
}
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84665
--- Comment #3 from Jakub Jelinek ---
Related to PR84940.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84940
Jakub Jelinek changed:
What|Removed |Added
Keywords||error-recovery
Priority|P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84908
H.J. Lu changed:
What|Removed |Added
Resolution|INVALID |MOVED
--- Comment #7 from H.J. Lu ---
It is a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84945
--- Comment #6 from H.J. Lu ---
(In reply to Jakub Jelinek from comment #2)
> Created attachment 43696 [details]
> gcc8-pr84945.patch
>
> Untested fix.
> I think this ought to work well on x86_64/i?86-linux, but I'm afraid is
> going to be an AB
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84761
--- Comment #1 from Florian Weimer ---
This bit needs to change for glibc 2.27 and later:
#ifdef __i386__
# define DL_INTERNAL_FUNCTION __attribute__((regparm(3), stdcall))
#else
# define DL_INTERNAL_FUNCTION
#endif
We removed the regparm attri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84891
--- Comment #4 from ead ---
From my naive point of view:
- The c++ standard doesn't define how complex-number-multiplication should
work, it is implementation defined/gcc-specific (I'm not a standard-scholar, so
might be very wrong about it).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84938
--- Comment #2 from Jakub Jelinek ---
int &&a = 1 / ~-1;
is enough.
When we have
int &&b = 1 / 0;
this doesn't ICE. When creating TRUNC_DIV_EXPR for the latter, we don't set
the constant bit on it, because the last argument is integer_zerop. T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84761
--- Comment #2 from rguenther at suse dot de ---
On Mon, 19 Mar 2018, fw at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84761
>
> --- Comment #1 from Florian Weimer ---
> This bit needs to change for glibc 2.27 and la
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84938
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84891
--- Comment #5 from rguenther at suse dot de ---
On Mon, 19 Mar 2018, no...@turm-lahnstein.de wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84891
>
> --- Comment #4 from ead ---
> From my naive point of view:
>
>- The c++ standard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84950
Bug ID: 84950
Summary: UBSAN: libiberty/cplus-dem.c:4430:3: runtime error:
null pointer passed as argument 2, which is declared
to never be null
Product: gcc
Vers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84951
Bug ID: 84951
Summary: UBSAN: libiberty/d-demangle.c:209:14: runtime error:
signed integer overflow: 922337203685477581 * 10
cannot be represented in type 'long int'
Product
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84761
--- Comment #3 from Florian Weimer ---
(In reply to rguent...@suse.de from comment #2)
> I think as there are already quite some __GLIBC_PREREQ uses in the
> sanitizer lib changing the above prototype appropriately would be
> good enough.
If th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84929
--- Comment #3 from Richard Biener ---
Author: rguenth
Date: Mon Mar 19 12:49:30 2018
New Revision: 258643
URL: https://gcc.gnu.org/viewcvs?rev=258643&root=gcc&view=rev
Log:
2018-03-19 Richard Biener
PR tree-optimization/84929
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84761
--- Comment #4 from Jakub Jelinek ---
That won't really work, if you configure against one glibc version and run
against another one, that will still not work properly.
So I think we need something like:
--- libsanitizer/sanitizer_common/sanitize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84890
--- Comment #6 from Jonathan Wakely ---
I have very little sympathy for anybody who thinks that an automated message
from a compiler is "kind of personal", but how about instead of asking a
question or equivocating with "you may want to ..." just
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53281
--- Comment #8 from Jonathan Wakely ---
(In reply to David Malcolm from comment #6)
> It seems best to special-case the "const member fn/param called with
> non-const" cases and to report them directly in terms of the types in user's
> source wit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84761
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84918
--- Comment #2 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #1)
> I'd much rather see a solution to the more general problem of drowning the
> user in information when the overload set is very large.
Which is now PR 84920
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84761
--- Comment #6 from Jakub Jelinek ---
Filed https://reviews.llvm.org/D44623 upstream.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84761
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84761
--- Comment #8 from Jakub Jelinek ---
Distributions should never backport symbol additions to symbol versioned
libraries, unless they backport all the corresponding changes.
So no, I don't think this is an issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84812
Nathan Sidwell changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84812
--- Comment #3 from Nathan Sidwell ---
Author: nathan
Date: Mon Mar 19 14:07:07 2018
New Revision: 258644
URL: https://gcc.gnu.org/viewcvs?rev=258644&root=gcc&view=rev
Log:
[C++/84812] ICE with local fn decl
https://gcc.gnu.org/ml/gcc-patches/2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84935
--- Comment #2 from Jakub Jelinek ---
Is that with r258590 in? I don't think hppa* is vect_int_mult effective
target.
1 - 100 of 259 matches
Mail list logo
